Originally Posted by jas0nuk View Post
elgordoeste: The topic was intended to work out how to regenerate it, but it appears we've hit a dead end until 1) a new jigkick is leaked and it gets decrypted and reversed, 2) a miracle, or 3) someone finds a hidden method in the PSP to regenerate the keys.
Don't expect anything to happen within the next month or two... or six.


Now that is really sad. Iv been reading everything U guys R doing to figure out the ID Storage and it really seems to be very hard to do. Is sad because now morons like me that didnt backed up the NAND before downgrading cannot use the UMD drive or can only update the PSP using el famoso Despertar del Cementerio.

Anyway, nice JOB guys.

EDIT:

So how exactly does it works? Just to have an idea! The hardware ie the UMD Drive has an encrypted key that matches the 0x102-0x106 in the id storage? So it compares those keys and if they matches it uses the idstorage one for security?? Or is it just the key from the idstorage that has the code to make it work??

Thanks

Just idstorage got the keys. So fuck up 102-106 -=> no more UMD.

SAD!!! :-(

What about the CFWs? U guys R going to keep working on those right? cuz based on what U saying, we, the ones that R f*cked up the only way to update FW is via DC.

SAD!!! :-(

What about the CFWs? U guys R going to keep working on those right? cuz based on what U saying, we, the ones that R f*cked up the only way to update FW is via DC.
First of all, we didn't make you flash that NAND dump.
Second of all, if we had a viable method of regenerating IDStorage, you'd know about it.

Keys like 0x0102-0x0106 can't just be faked or rebuilt at this point, they are used in the UMD sector decryption process, if they're corrupt, decryption fails. Custom firmware can't fix that.

You can't update, because you've changed key 0x0100, which when changed (to anything) reads invalid, preventing updaters from running. There is no workaround to this.

So yes, Despertar del Cementario is the only way you can update. The problem is known, it's a pain, but there just isn't any other way if you've corrupted IDStorage. No amount of complaining will solve this, if you're pissed off about it, I suggest you start working on a way of solving your problem, instead of complaining why we haven't.

It is because of people like you that you dont get the support U need.
First of all I was not complaining. I think M33 and DAX R the best ever. You have to be a fucking genius to do stuff like M33 can do.

I know I have a fucked up IdStorage. I just wanted to know if DAX will continue to program cfws. I happen to be a c++, c#, delphi, c, v, vb.net and assembly programmer so I understand what is going on.

Dont want and didnt want to sound like I am upset.

BTW -> you wrent with me when I fucked up my idstorage so DUH!!! No one is blaming on U. #$%^&

Anyway. Wont Post again in LAN.ST. I dont like when people who think they know everything just start talking trash.

See ya in HELL...........from heaven of course!

everyone please calm down, this happen to be a DEVELOPMENT forum, not an elementary school backyard. Thank you for your understanding.

And what bring_vg said is true, if we had any way of generating signed idstorage keys we would have posted it publically by now. To be honest I don't even think there is one or it is possible without very extensive hardware involved (for each psp to restore that is) as from my point of view dumping the syscon chip microcode containing the kirk id is the only way to do it and considering this very id is unique per psps it would require to read the microcode of all syscon chips, it's nonsense.

Anyway if there is another way to do it then we haven't find it yet, but the best way to fix your problem is I guess to get another psp (it would be far less expensive than the equipment needed to read the syscon's chip microcode xD)

MathieulH, did anyone try decryption of the UMD-keys with key 0x0140?

PSP-2002 Aus/NZ Piano Black key 0x0140:

60 6A D7 FB 7F D4 B8 09 B2 68 0E 1D 0A 41 51 38 DC DF CB B0


In case anyone wants it...

EDIT: As far as I can tell, corrupting the key doesn't do.... anything. KIRK seems to work just fine, PRX decryption still works at least.

Mathieulh, if you were able to reverse one syscon chip to see how it was encrypting the original keys from some generic ID, couldn't you use that to find the original ID?

I don't know anything about IPL programming, but couldn't you build an IPL from scratch that just ran that generic ID back through the syscon to rebuild the keys?

I also may not know what I'm talking about, and if I said something stupid, please correct me. :cool:

I think the main point that was made is, by the time you have reversed one chip using invasive methods, you will be very broke from paying for the hardware to do it with.

Keys like 0x0102-0x0106 can't just be faked or rebuilt at this point, they are used in the UMD sector decryption process, if they're corrupt, decryption fails. Custom firmware can't fix that.

I'm wondering about the UMD keys and whether they involve a per-psp kirk or if they only involve the UMD drive. I seem to remember that if you pull the UMD drive from one unit and put it into another the drive still wont function. I'm wondering if you pulled a drive and associated keys from a unit and placed it into the second if the drive would work. This would indicate that for these keys they only enable the decryption of the data streaming from the drive. Unfortunately I dont have the hardware resources to test it, but wondered if someone else might think it worth testing. I'm not even sure of the value of the answer if we knew. If the drive works in the second unit, then the key is the public side of a public/private encryption with the private encryption happening in the drive mechanism. If the drive doesn't work, then it doesnt work and we dont really know why (key involves per psp kirk, or some other reason).

I seem to remember that if you pull the UMD drive from one unit and put it into another the drive still wont function.

If you look online there are plenty of sites that sell replacement UMD drives.

EDIT: this suggests that replacing the UMD drive will work without any change to IDStorage.

EDIT2: see this link for instance: http://gamerscrew.com/html/repair-part/psp-laser-replacement-and-psp-disassembly-tutorial.html

My bad, thought I'd read a couple of posts in the past talking about this problem. Either I read some mis-information or the senility is kicking in harder than usual.

The TA-085 V2 has somewhat poked a hole in our assumption that all batteries start off with 0xFFFFFFFF, since new Slims can no longer write to EEPROM. Perhaps they've only changed that part of the line, and IDStorage is generated on the first run....

The TA-085 V2 has somewhat poked a hole in our assumption that all batteries start off with 0xFFFFFFFF, since new Slims can no longer write to EEPROM. Perhaps they've only changed that part of the line, and IDStorage is generated on the first run....

Nah, they use special prepared batteries to start the initial generation of the ID Storage. I wonder if Sony replaces the motherboard and if the motherboard contains an empty nand.

The TA-085 V2 has somewhat poked a hole in our assumption that all batteries start off with 0xFFFFFFFF, since new Slims can no longer write to EEPROM. Perhaps they've only changed that part of the line, and IDStorage is generated on the first run....
Or perhaps they have just randomized the commands (or changed the params) to write/read the prom in a byte-wise fashion, and left the functions out of retail firmware so we'd have nothing to reverse... to me the evidence suggests that is what is going on.

The TA-085 V2 has somewhat poked a hole in our assumption that all batteries start off with 0xFFFFFFFF, since new Slims can no longer write to EEPROM. Perhaps they've only changed that part of the line, and IDStorage is generated on the first run....
Or perhaps they have just randomized the commands (or changed the params) to write/read the prom in a byte-wise fashion, and left the functions out of retail firmware so we'd have nothing to reverse... to me the evidence suggests that is what is going on.
How dare they start realizing and fixing their mistakes! :(

Yes, as already made Pandorii (lol) still work, that makes sense, the only thing that will have changed is a small part of the read/write, which doesn't affect them at all, but has us dead in the water.

Bastards. :D

Probably just moved the battery write/read commands to a different number :P

As I see and understand it (which might likely be wrong....) the commands and/or hardware to write to the battery EEPROM *must* still be there anywhere.

AFAIK the EEPROM not only holds the serial, but vital status information of the battery as well.
That information is maintained and updated by the device the battery sits in and maybe a bit by the battery itself.

I think they just added some sort of security check,
Another option would be, they really blocked write access to the bytes containing the serial completely in the syscon, since the serial is indeed not intended to be changed, so blocking write access to those positions wouldn't break anything....


Does this actually make sense, or am I lightyears off track?

Could anyone make a small program Visual Basic or C or a Javasript page that Prints out the NID once the "guess" is inputted.

Sort of like this:
http://img220.imageshack.us/img220/3117/iamgetn6.png (http://imageshack.us)



I could make some intelligent guesses. Instead of going through websites and getting the SHA and reversing it's bits and checking if I got something luckily.

I got a quick question, other then the umd decryption and magicgate memory stick's is the id storage accessed outside of the firmware.

Yes, the WLAN adhoc authentication uses key 0x100

Could anyone make a small program Visual Basic or C or a Javasript page that Prints out the NID once the "guess" is inputted.

Sort of like this:
http://img220.imageshack.us/img220/3117/iamgetn6.png (http://imageshack.us)



I could make some intelligent guesses. Instead of going through websites and getting the SHA and reversing it's bits and checking if I got something luckily.

Just diggin' :p

Hello everyone I upgrade the PSP's serious problems encountered
For the error code : CAT80000025 I would like to ask how can we solve this problem??????:confused::confused::confused:

As I see and understand it (which might likely be wrong....) the commands and/or hardware to write to the battery EEPROM *must* still be there anywhere.

AFAIK the EEPROM not only holds the serial, but vital status information of the battery as well.
That information is maintained and updated by the device the battery sits in and maybe a bit by the battery itself.

I think they just added some sort of security check,
Another option would be, they really blocked write access to the bytes containing the serial completely in the syscon, since the serial is indeed not intended to be changed, so blocking write access to those positions wouldn't break anything....


Does this actually make sense, or am I lightyears off track?

Makes sense totally.
Back in 2002 PS2 hackers figured out that PS2s had their Serial numbers and iLINK IDs in plaintext on the mechacon eeprom. That was exploited to the exaustion and sony's response were a new mechacon design called "dragon" (CXR706080) on the 5000x and all Slimline PS2 series.

That chip has the eeprom and realtime clock moved to it's die, firmware is patched to disallow writes to the serial number and iLINK regions of the eeprom, as well. Also the protocols for the mechacon debug and diagnosis serial port were changed (Sony mechacon software tools that work with models up to SCPH-3900x were leaked from Sony authorized service and are available if you know where to look).

You see ... this kind of fixing is not only trivial but they have messed this up earlier ! lol

I've presumed all along that the commands still exist, either with a changed command number or specific parameter changes - and that the removal of those functions from 3.80 was their method of not "leaking" those changes in public firmware.

Changing the commands to read the prom doesn't have to change anything else like hellcat presumes though, since there are other commands and they don't necessarily have to rely on reading/writing the prom, as far as I can tell there is a challenge/response protocol that the PSP uses to "converse" with the batteries' onboard microcontroller which would already have direct access to all the info in the prom to formulate it's responses to things like capacity.

What would be nice is a low level routine/addresses that lets us formulate data going directly to that 1wire serial bus, so we don't need syscon to play the middleman. Whether that is possible... I don't know.

edit:/ not sure if this would work, but has anyone tried sending all possible commands to syscon to at least list which commands exist and which come back as unsupported? Perhaps one way of seeing if they just changed something simple like the command number.

Well, they put the functions in there for a reason in pre 3.80, so the FW seems to use the access to the battery.

Let's assume 3.80+ still does, so somehere in the MBs of the firmware there is code that acesses the battery....
....how are chances of "scanning" the .PRXs for code that accesses the battery? It should have some sort of "pattern" to look for, wouldn't it?

edit:/ not sure if this would work, but has anyone tried sending all possible commands to syscon to at least list which commands exist and which come back as unsupported? Perhaps one way of seeing if they just changed something simple like the command number.

Of course! What do you think :p. Though I havent listed changes between different syscon versions (I simply dont have that many different PSP models to test).

Internally sure the command would most probably still exist, the simplest change would be to the interface only.

Looking at how that Datel battery converter works would sure provide some clues (especially for the challenge response).

EDIT:
Ok, here's my compiled list. It should be pretty complete. Some cmds have changed over versions, ie. only existed on an earlier version of SYSCON, or was changed to something different on a later version, or only on fat, or only on slim, etc.

A good example is cmd 0x4A, earlier SYSCON versions had that cmd mapped to GetPowerError, later GetPowerError was removed completely and cmd 0x4A then became CtrlHddPower.

I should also note that not all values are used. Cmds are from 0x00-0x7F, there aren't 128 cmds being used so if it says UNK it's not used (unless I've put a comment next to it saying the cmd exists but do not know what it does, usually because the nid hasnt been cracked). Example being cmd 0x23/0x24 which are being used quite a lot. But have no idea what it is.

http://pb.malloc.us/f56ce75ce

EDIT2:
Well, they put the functions in there for a reason in pre 3.80, so the FW seems to use the access to the battery.

Let's assume 3.80+ still does, so somehere in the MBs of the firmware there is code that acesses the battery....
....how are chances of "scanning" the .PRXs for code that accesses the battery? It should have some sort of "pattern" to look for, wouldn't it?

SCE are pretty lazy :p. They will reuse the same prx over & over on all their machines, devkits, testing tools, etc. (saves them from having to make a seperate version for each type). That is why you still see devkit only code in the fw which only runs on a devkit. The syscon.prx is used as a lib, so it's exports are not necessarily used in the fw itself (only small fraction of exports are actually used in the fw, and I assure you the read/write eeprom functions are DEFINITELY not used), but having a complete interface means that they are still able to use them in their internal apps on their internal machines (when doing testing etc). Frankly Im surprised these sceSysconBatteryReadNVM/sceSysconBatteryWriteNVM exports ever existed at all on the retail PSP.

Of course! What do you think :p. Though I havent listed changes between different syscon versions (I simply dont have that many different PSP models to test).
Ok, so I give this list to a guy with a newer PSP and they are just going to go "like wtf dude" or something equally inane. My thought is does syscon return a specific error if you feed it a command with no params at all, or will it always return hardware error like we are seeing with the revised slims if the params are not correct (really gotta get this mess I've got going cleared up and do some of my own legwork on it for my own curiosity.) And in the end, I guess I'd have to ask, would it even be safe to ask someone to brute/randomly try something that issues these commands on hardware (or advisable, you saw how long it took just to get that single error code, no thanks to me though xD)

From what I have seen of others logs, comms are not crypted between the battery and the PSP. It's likely the datel device just fakes the initial handshake, issues the commands to write the prom and away it goes. It's semi-documented by nem and other's analysis over at ps2 dev, as far as I can tell it'd be a fairly common single wire serial protocol which should be well documented right down to the timings. It may well even be possible to hijack the battery comms using a standard serial interface.

My thought is does syscon return a specific error if you feed it a command with no params at all, or will it always return hardware error like we are seeing with the revised slims if the params are not correct (really gotta get this mess I've got going cleared up and do some of my own legwork on it for my own curiosity.) And in the end, I guess I'd have to ask, would it even be safe to ask someone to brute/randomly try something that issues these commands on hardware (or advisable, you saw how long it took just to get that single error code, no thanks to me though xD)

Yes it will return 0x83 error if params are wrong (or 0x80250083 is what you'll really see returned by syscon.prx, the syscon chip itself returns 0x83). The 0x84 error that the new slims are returning means that the cmd is not recognised, you'll get that same error trying any other unused cmd. I just dump the whole syscon packet after executing the cmd to see if there are any other (minor) changes when it fails for those cmds. I'll give you a sample code to test (a funny bit I found, the SYSCON chip uses the 0xDEADBEEF moniker for their invalid addresses, cute).

About sending cmds via hw, it wont make a difference, it will just be the same as doing it in software. Basically:
CPU -> SPI bus -> SYSCON -> some 1-wire serial bus -> Battery. So sending the packet to syscon via HW on the SPI bus is no different than using the software interface. It's the way Syscon recognises these cmds in it's fw that determines what it will then do to the battery. And the only current way to work with Syscon is via this interface (though Im always hopeful for breakthroughs).

Will there be a way to regenerate corrupt ID Storage one day?:rolleyes: I Have a PSP fat with corrupt ID Storage & keys (UMD,Sony's updater,Wifi & Remote Play) are not working:(.Everytime that i need to update my PSP to a new custom firmware M33 i need to wait for Dark_AleX's Despertar del Cementerio

About sending cmds via hw, it wont make a difference, it will just be the same as doing it in software. Basically:
CPU -> SPI bus -> SYSCON -> some 1-wire serial bus -> Battery. So sending the packet to syscon via HW on the SPI bus is no different than using the software interface. It's the way Syscon recognises these cmds in it's fw that determines what it will then do to the battery. And the only current way to work with Syscon is via this interface (though Im always hopeful for breakthroughs).
Yeah, I kind of figure syscon would be handling the hw interface but one can always hope there are direct address lines like the NAND has.

Fadil: at the present rate of discovery, I'd say no time soon (if at all.) But you never know, someone may well stumble into something that blows the lid off; then again, the PSP may well take it's secret to the grave, so to speak...

I don't know but I'm probably revisiting things people have already researched/discussed here. When the IDStorage was initially generated I would assume that kirk actually did the encryption on the unique keys correct? I guess we don't really know for sure but it would make sense wouldn't it. In which case kirk obviously has access to the encryption key as it seems to be believed that it is the kirk ID correct? So wouldn't there probably be some way of making kirk do whatever the factory had it do initially?

On another note, I would assume decrypting the unique keys would be a major step forward. After all, the unencrypted info would be necessary to regenerate the keys correct? wonder if a way to crack the encryption could be devised.

Like I said, all this has probably been discussed but 29 pages is a lot to read. I'm hoping to play around and see if I can figure anything out as soon as I get a working PSP again. I screwed up my idstorage just to find that my brother had deleted my nand dump off the computer.

I don't know but I'm probably revisiting things people have already researched/discussed here. When the IDStorage was initially generated I would assume that kirk actually did the encryption on the unique keys correct? I guess we don't really know for sure but it would make sense wouldn't it. In which case kirk obviously has access to the encryption key as it seems to be believed that it is the kirk ID correct? So wouldn't there probably be some way of making kirk do whatever the factory had it do initially?

On another note, I would assume decrypting the unique keys would be a major step forward. After all, the unencrypted info would be necessary to regenerate the keys correct? wonder if a way to crack the encryption could be devised.

Like I said, all this has probably been discussed but 29 pages is a lot to read. I'm hoping to play around and see if I can figure anything out as soon as I get a working PSP again. I screwed up my idstorage just to find that my brother had deleted my nand dump off the computer.
Correct, the problem is that were you able to retrieve the KIRK ID by hardware means (rather expensive means, I might add), you'd still have to repeat that process for each individual PSP. If the KIRK ID is the key to all this, unless one of the undocumented KIRK commands is able to access this ID, we're a tad dead in the water.

I'm purely speculating at this point but my theory is that one of the undocumented kirk commands may actually have been used in generating the idstorage. We won't know though until we can figure out the undocumented ones.

I'm purely speculating at this point but my theory is that one of the undocumented kirk commands may actually have been used in generating the idstorage. We won't know though until we can figure out the undocumented ones.
Indeed, sadly, I'm shit at C :D

eh, my C is rusty but I'll probably brush up on it. It would be awesome if we could find a way to regen the IDStorage though.

I think at this point it isn't so much C that is an issue, it is trying to understand "undocumented hardware that does dog only knows what internally" ;)

One also assumes (as in previous posts to this thread) that the key to generate idstore is actually kept somewhere in the process (even if it is to OTP flash inside the syscon or something equally odd), remember though that asym crypted data does not need the generating/private key to be decrypted.

Perhaps this would be a good point of speculation as to why they stopped writing an actual value to what we presume is the "serial" location in idstore (similar reasons to the removal of NVM routines from hardware recently.) I wonder if anyone has tried anything with syscon and that specific key, or for that matter if that key is used in any of the pre-nulled on hardware firmwares...

I think at this point it isn't so much C that is an issue
It is for me, since testing has to be done painfully and slowly since I can't write my own programs for crap :D

EMO posted the text below on maxconsole, however I do not know if it is true.
If it is true, then it might contradict what we know in a way. It could mean that there just a "few" entry's possible in the ID Storage for the UMD key.

Link to comment 1 (http://forums.maxconsole.net/showpost.php?p=858487&postcount=10)

if he used a 1.50 firmware (only) nand dump from another PSP it will work as my phat psp fully bricked long time ago and i make an 1.50 firmware nand dump from another PSP and it's worked so try to find some one with a homebrew psp to make a dump for you

I asked him: (http://forums.maxconsole.net/showpost.php?p=858684&postcount=11)

Are you very sure? Normally the UMD-drive shouldn't be reading a UMD and WiFi Ad-Hoc should fail.

His answer: (http://forums.maxconsole.net/showpost.php?p=859814&postcount=12)

No every thing is worked with me but be sure not to make a nand dump with idstorage.

Can this really be true?

EMO posted the text below on maxconsole, however I do not know if it is true.
If it is true, then it might contradict what we know in a way. It could mean that there just a "few" entry's possible in the ID Storage for the UMD key.

Link to comment 1 (http://forums.maxconsole.net/showpost.php?p=858487&postcount=10)

if he used a 1.50 firmware (only) nand dump from another PSP it will work as my phat psp fully bricked long time ago and i make an 1.50 firmware nand dump from another PSP and it's worked so try to find some one with a homebrew psp to make a dump for you

I asked him: (http://forums.maxconsole.net/showpost.php?p=858684&postcount=11)

Are you very sure? Normally the UMD-drive shouldn't be reading a UMD and WiFi Ad-Hoc should fail.

His answer: (http://forums.maxconsole.net/showpost.php?p=859814&postcount=12)

No every thing is worked with me but be sure not to make a nand dump with idstorage.

Can this really be true?

Well, if you have a brick non IdStorage dependent ... I think ...why not (imho).:D

A stupid question however someway topic related:

I'm not native I'll do my best to be clear.

The point to me seems to be HW related.

All of you knows that flashing an installation image build on a machine over another one in most cases will lead to crashes but replacing a component will often only lead the system to a need of an update.

IdStorage is, encrypted or not, and callit whatever you want, nothing more than a registry and this is proven on the bases the system itself rewrite some of it's keys for BS things like the 0x054 key (display colour it seems...)... ok ?

Well if the system can write an encrypted key for such a stupid thing why couldn't do the same thing for other questions ?

Does anyone ever tried to make a IDS backup of a fully working unit with a fully working UMD unit and a make another one after replacing the UMD unit with another fully working one ?

Does something changes in the IdStorage after the move ?

Does the unit have the ability to update it's IdStorage keys whether detects hardware changes ?

UMD unit is a replaceable thing and when it's replaced due to overwork the main unit with the new one laser unit works again ...it's not ?

In many systems the OS store hardware related infos in a registry, encrypted or not, does the psp do the same thing ?

If it where so all would be a little more simple, it should means the kernel at his wish CAN rebuild IdS HW related keys...

I now, it's an hammer'nd chisel test but ...:D

EMO posted the text below on maxconsole, however I do not know if it is true.
If it is true, then it might contradict what we know in a way. It could mean that there just a "few" entry's possible in the ID Storage for the UMD key.

Link to comment 1 (http://forums.maxconsole.net/showpost.php?p=858487&postcount=10)

if he used a 1.50 firmware (only) nand dump from another PSP it will work as my phat psp fully bricked long time ago and i make an 1.50 firmware nand dump from another PSP and it's worked so try to find some one with a homebrew psp to make a dump for you

I asked him: (http://forums.maxconsole.net/showpost.php?p=858684&postcount=11)

Are you very sure? Normally the UMD-drive shouldn't be reading a UMD and WiFi Ad-Hoc should fail.

His answer: (http://forums.maxconsole.net/showpost.php?p=859814&postcount=12)

No every thing is worked with me but be sure not to make a nand dump with idstorage.

Can this really be true?

Yes if it's a mess wich doesn't involves IdStorage...


Another stupid question:

Does anyone ever tried to compare IDS of a fully working unit after replacing a fully working UMD unit with another fully working one ?

Do the kernel does some changes in IDS ?

After all, encrypted or not, IDS is a bare registry or I've screwed my brain, do I ?

Since the main unit uses it for stupid things as the backgorund color is and encrypts a key only to remember it... afaik the hardware config is more than that...

Let's figure out an OS image with the kernel build on a machine and slapped to another machine kind... it wont work, but swapping only a device... the system may identify the new hardware... moreover in our test all the change is an hardware ID...

Well if the psp does the same thing (replacing an UMD with a broken lens seems to work anyway quite well and without troubles) AND changes it's internal hardware cofiguration ... I'll leave you all the rest...

From the sounds of that discussion EMO is pulling someones leg or isn't getting their point across completely. There is a good reason why this thread is an ongoing discussion.
No every thing is worked with me but be sure not to make a nand dump with idstorage.
Probably means be sure to not flash idstore from whatever nand dump is made.

Well I'll go straight to the point as fast as I can unless I must spend few words.
When replacing due to overwork a cranked-up UMD unit a psp reads again without troubles, right ?
Do someone has tried to watch if IdStore changes in some way after an hardware replacement of a unit like UMD and Wi-FI ?
I now It may seems a dull question but let we analyze facts from another point of view:
An IdStorage is nothing more, nothing less than an encrypted callit wathever you want registry...but why in a registry can't be buried a "driver" ?
The system seems to have no problem to write in it since IF it's finally confirmed some keys changes seemingly to one storing default ?? background color ??
Do encryption changes between a key and another ?
At SCE are they so perverted ?
If not, are you focusing the point ?
The system knows how and where to write.
Moreover 1.50 updater add two keys to IdStorage to fix language in 1.00 version, right ?
Yes maybe it only does a chek of the stuff like MB 'nd OS version doing a "non per unit" patch, perhaps this isn't a good point but even in this case there must be the patch buried somewhere into the updater...
Never mind... not very helpfull, I don't really know where this can lead to...only before trying voodoo stuffs on a syscon maybe someone can give a check to theese ideas...
What I mean is, does an fw installer give a check at IdStorage ?
Yes it does, how come it do its checks only on a few bunch of keys instead to the whole batch ?
It's not it knows many keys can change, it is ?
It understands IDs or does a basically "encrypted mirror check" ?
Then...
... a key from a mobo wont work in another one but do an encrypted driver built for a device 'nd hardware signchecked can run on another machine even for the same device ?
Do the machine itself recode the "driver" when it's detected an hardware change, encrypting it with it's own "wtf" microcode AND the new device microcode?
Do you understands where I'm aiming to ?
I'm not a really full fledged coder, I know it, my field is "logic"....don't blame me if I've told a bunch of BS but I'm concerned into this thing but things runs on my minds and trying to give somehow my support I fired them off...
Moreover I'm not native... I hope to have not mispelled something...

I've edited this post trying to explain better my point of view.

moneymaker: logic dictates you have not read or gotten what has come before.

Changing the UMD drive out doesn't require any software alterations, as the drives all feed the same data to the PSP (the data that is permanently crypted on the UMD, to be precise.) Changing the wifi module only requires altering the mac address in idstore to make it work fully (IIRC adhoc gets broken if you don't).

The problem is, there are a set of unique keys that are set up to decrypt from idstore on a per PSP basis (they are crypted to the PSP they are on at some point during manufacture), and they contain the data that is used to do things like validate region, PSID, and provide the decryption key for the data that comes off the UMD drive. It's been posited that some of this can be bypassed via software hacks (and in some things like region this is already partially done in custom firmware), but exactly how well that would work, whether it would work or is tied more strictly to hardware like syscon, and whether it is trivial to re-hack each new firmware - is another question entirely.

I definitely can't say the hardware is fully understood, but IF (big if) 1.00 to 1.50 did update the idstore at all the changes were likely trivial (first I have ever heard of any official updater making any changes to idstore at all.)

I definitely can't say the hardware is fully understood, but IF (big if) 1.00 to 1.50 did update the idstore at all the changes were likely trivial (first I have ever heard of any official updater making any changes to idstore at all.)
Plus (I'm not entirely sure which keys we're talking about here) if the keys written aren't unique, they don't require generation, just writing as how KeyCleaner does it.

logic dictates also the whole 100-106 key isn't THE key used for UMD decryption but a very small part of it must be.
I figure out how many processor cycles needs a strong key from the (2) core unit(s).
They must 've chosen a secure but fast path to not have the system sucks up the poor 3.6 volt battery too much.
Obviously processor knows exactly which to look of those 3136 bytes for decryption purposes if this is true.
At the end what could it be ? A bare metal assembler serialized processor microcode extension ?
I'll do some exp. on it... first of all I'll try setting all those bytes to FF watching the effects ...then I'll do some test on the code and only on it.
I'm not here crying "help me, i've screwed my precious psp", it's more fun than use it for what it's intended... thus if there some voltage control on it...well, then I microwave it and post a video on youtube, ok ? :D

Setting it to all FF just produces a 'The game could not be started. The region code is incorrect' every time you try to launch... anything... from my testing.

NO updater has EVER written to idstorage. NO firmware has EVER written to idstorage. NO app/game has EVER written to idstorage (not including 'homebrew' apps).

In short, NOTHING has ever written to idstorage (apart from when they were first written at factory and at service/repair centers).

EDIT:
Also when replacing the "umd drive", what you are really replacing is just the optical pickup unit. All the corresponding electronics are on the motherboard itself. So these type of replacements are perfectly fine. But even if the umd drive had an embedded controller (like a dvd drive) replacing it would still be fine since the umd drive doesnt do the decryption, just reads the (encrypted) data off the disc.

logic dictates also the whole 100-106 key isn't THE key used for UMD decryption but a very small part of it must be.
I figure out how many processor cycles needs a strong key from the (2) core unit(s).
Indeed, I also presume the full key isn't easily accessible intentionally (to prevent counterfeit and unlicensed UMD.)
Obviously processor knows exactly which to look of those 3136 bytes for decryption purposes if this is true.
The PSP has a couple crypto engines in it, I presume they have to be set up in some fashion requiring the idstore data (even if it is only used as per-psp auth against something that is programmed at manufacture to simply allow an internal function to work or not work.) As to what the chips are actually doing internally, don't know - but the idea of mux/demux comes to mind, and that they had the opportunity to have the chips designed for a single purpose (and thus be power efficient.)
I'll do some exp. on it... first of all I'll try setting all those bytes to FF watching the effects ...then I'll do some test on the code and only on it. I for one hope you have patience and better hardware than I do for looking into such things ;)

BTW... skip the microwave, sparks aren't that impressive even when they are inside a plastic housing :D

Indeed, I also presume the full key isn't easily accessible intentionally (to prevent counterfeit and unlicensed UMD.)

Most likely is it so, but the reason doesn't exist, I've never seen an umd dupe.

Games development is done on dedicated virtual machines and when the job is done the 9669 goes straight to the crafting factory, after some tests mass production starts.

UMD duping cannot be a business, all of you knows it well.

Then why they use 128 bits AES encryption for that drive ?

Perhaps the key is an hand painted Japanese character binary translation's CRC2 with meaning "suckthis" plus its byteswapped mirror (just ignore this, please).

But..even if we manage to find those cursed 16 bytes, wtf...?

For sure I can confirm 0x5 and 0x12 are the same (at least in euro version) on TA081(1004H) and TA085(v2 reasonably, cause noway to battery eeprom) (2004PB Italy, UK import) when 0x10,0x11,0x13 changes and mine TA085 also shows a (reintroduced) 0x050...
I'm analyzing 100-106 differences between the two.

hei there, a little help needed , i have a TA-82/86 system, i m having problem upgrading 3.80m33 to 3.90m33 and it appears to be the idstorage keys fault, of which i get a code of DRNFFFFFFB0, can anyone help me on rebuilding it back , any help would be greatly appreciated!!

hei there, a little help needed , i have a TA-82/86 system, i m having problem upgrading 3.80m33 to 3.90m33 and it appears to be the idstorage keys fault, of which i get a code of DRNFFFFFFB0, can anyone help me on rebuilding it back , any help would be greatly appreciated!!

Go to help section!

hei there, a little help needed , i have a TA-82/86 system, i m having problem upgrading 3.80m33 to 3.90m33 and it appears to be the idstorage keys fault, of which i get a code of DRNFFFFFFB0, can anyone help me on rebuilding it back , any help would be greatly appreciated!!

This is a development forum. If you would have googled a little you would have found that this issue can easely be fixed by tools such as keycleaner.

again this is the kind of requests to do in noob friendly boards (such as exophase, maxconsole etc etc) Please look at proper documentations and tutorials before asking questions here.

HI all,

In my homebrew I am using sceIdStorageLookup to retreive the MAC address, it works fine for both a Fat or a SLIN.
When I am trying to look up the same MAC address in the dump file (of the NAND), I can find it for the FAT, but not in the SLIM ones.

Did I miss something ?

When I am trying to look up the same MAC address in the dump file (of the NAND), I can find it for the FAT, but not in the SLIM ones.
Yes, you missed the fact that a NAND dump of a slim, unlike the fat PSP, has the idstore crypted; when running PSP firmware idstore driver takes care of the decrypt but the NAND driver still gets access to the crypted data.

damn!
Thank you cory1492.
my intention was to read the MAC address in the dump and compared it to the one retreived directly from the idstorage to be sure to reflash the right dump to the right PSP...

When I am trying to look up the same MAC address in the dump file (of the NAND), I can find it for the FAT, but not in the SLIM ones.
Yes, you missed the fact that a NAND dump of a slim, unlike the fat PSP, has the idstore crypted; when running PSP firmware idstore driver takes care of the decrypt but the NAND driver still gets access to the crypted data.

hi Cory1492 , i have been following u guys with the id storage issues. really hope i can contribute some help.
i m not a programmer but i may be able to give u nands from few hundreds sets or even thousands for u guys to do comparision. or if u guys needs any hard ware data just let me know if i can contribute but i need instructions hee...i have extracted them from vga of phat machine thru the hard way before the m33 is release. all the best to the development .

Wont the final UMD decryption key be stored in memory (probably some HW controller mem) while the drive is reading?

I presume the UMD decryption key is got after decryption of corresponding IDStorage keys.

But if the final UMD decryption key is obtained, then that key will decrypt ANY UMD on ANY PSP right?

Is it possible to force the use of the obtained key, regardless of the IDStorage state, either by using specialized CFW (if such low level access is possible) or at worst by a hardmod?

Thought it wouldnt really be IDStorage regeneration, it would still be restoration of functionality.

Wont the final UMD decryption key be stored in memory (probably some HW controller mem) while the drive is reading?

I presume the UMD decryption key is got after decryption of corresponding IDStorage keys.

But if the final UMD decryption key is obtained, then that key will decrypt ANY UMD on ANY PSP right?

Is it possible to force the use of the obtained key, regardless of the IDStorage state, either by using specialized CFW (if such low level access is possible) or at worst by a hardmod?

Thought it wouldnt really be IDStorage regeneration, it would still be restoration of functionality.
The key is probably stored in the UMD controller hardware or some other low level memory. It is obtained from the decryption of the keys, and probably some constant which is stored elsewhere. And yes, the final key will decrypt any UMD on any PSP.

If that key can be discovered, it may or may not be possible to force the PSP to use it, depends where the key is stored while it's being used.

And finally, that doesn't classify as IdStorage regeneration, but it's good enough. The aim here is to restore PSP functionality, if we can do that without regenerating the IdStorage, then that's good enough ;)

Correct if I am wrong, but are the ID Storage Keys for the UMD read and decrypted at boot from the IPL or when a UMD is accessed or initialized?

If it is the within the firmware, then possibly a program can hook into that.
It could be used for a slow brute force attack.

Correct if I am wrong, but are the ID Storage Keys for the UMD read and decrypted at boot from the IPL or when a UMD is accessed or initialized?

If it is the within the firmware, then possibly a program can hook into that.
It could be used for a slow brute force attack.
Even if it was in the IPL, it still won't matter as we've got custom IPL blocks now. However, such a bruteforce attack would take millions of years, it simply isn't going to work.

I know JumpR, but I haven't seen any other option at the moment. have you?

I know JumpR, but I haven't seen any other option at the moment. have you?
Well, breaking the encryption chips using invasive methods :p Gathering money to afford that would even take less long then such a huge bruteforce attack I guess. Seriously, it's going to take millions of years, it just isn't an option.

Jachra: stop, just stop.

Brute force isn't going to help, the likelihood of literally stumbling across the correct key within your lifetime is NIL, the size of the data is just too bloody big to one shot guess the thing.

Unless the hardware itself can be completely understood (again, fairly unlikely unless there are leaks I don't know about or someone with the skill and desire to do it rather than hound a forum with what is already understood by most as being a.. "very bad idea") and some form of timing attack can be made to help so that the entire key can be broken into smaller bits and guessed in small chunks (the reward, skill and hardware costs to do so would likely make purchasing a new PSP cheaper in the long run), put bluntly in a loud "voice" so you stop suggesting it as viable as it seems you aren't trying to attain the skill to do it yourself but have been suggesting someone do it for you:
THERE IS NO HOPE OF ONLY DIRECT BRUTE FORCE SUCCEEDING BEFORE THE HARDWARE FAILS.

There are always two options available in the case of a lost idstore:
- just use the thing for parts and get a different one, and chalk it up to "I/they/their brothers/their friends/whathaveyou should have made a backup before messing around with unofficial software."
- sit on your hands and hope someone comes up with something. There are definitely people who are vigilant (and a few of them have suggested things that may be possible in circumventing the key issue that have nothing to do with brute forcing anything) in looking for a slip or indication that would give us what we need. That said, you never know if or when someone will get a key piece of info that they have been lacking to solve such a puzzle - but I do know popping up every so often to try and get someone to write something that will attempt to brute force the thing for you definitely isn't that key piece of info...

Sorry if it seems like I'm being hard on your brute force enthusiasts, but suggesting it without going into trying it yourself is just pointless and lan.st these days is a development board not a wishlist or request space. Just try doing your own bit table and see how long it takes, and then perhaps you'd understand the odds fundamentally. Here, I'll start one for you... maybe this will be enough to keep you occupied until well after you are dead an buried :(
0
1
10
11
100
101
110
1000
1001
1010
1011
1100
1101
1110
1111
etc., until you get to all combinations for the actual key's bit length. That's only 4 bits, or half a byte (nibble), the combinations are exponential for each bit you add.

Cory1942

I am making such program and I am not requesting it on anyone to make it for me or anyone else. I am only stuck in how I can hook a function in the firmware.

I am aware that it will take long to brute force it. Could be several years or more, but I find it a nice study object to be able to create it.

I know Lan.st is a dev board and nothing like maxconsole or even qj.net.

Cory1942

I am making such program and I am not requesting it on anyone to make it for me or anyone else. I am only stuck in how I can hook a function in the firmware.

I am aware that it will take long to brute force it. Could be several years or more, but I find it a nice study object to be able to create it.

I know Lan.st is a dev board and nothing like maxconsole or even qj.net.

... No, just no. Hooking a function in the firmware really isn't going to help. You'll need to research the modules that decrypt the UMD, and even if you manage to do so, it'll still take millions of years (not a couple of years, millions of years).
Seriously, what you're trying is nonsense.

I have to agree with cory1492 bruteforcing the key will likely take longer than your own lifetime so I don't really see the point.
Also the umdman (and not the IPL) does not decrypt idstorage keys on its own, it just "asks" kirk or spock to do it for him (kirk also checks the keys integrity of course) and then kirk (or spock) returns the result (likely the key in its decrypted form) of course idstorage keys are encrypted using the kirk/spock ID which we cannot dump since it is located somewhere within the syscon die. (I highly expect that not even sony can retrieve it, at least not using software.)

JumpR

I know it will take very, very long, That is why it will never be released. For me it is a study object. To see what I can make with the PSP. It is for me and me only. Just to see if I am able to do it and learn from it. Nothing more, nothing less. I do have to start somewhere, so why not this. Many more of some sort of software will be created by me, until I can create what I want to make for a very long time. That software might be released or not, at this point I really do not know.

I know my C/C++. I can read and change someone else code, but I feel that I do not learn much of it. It is nice to see how someone made something. In a sense it gives a insight how fellow programmer works and how he/she is. How he/she thinks and so on.

Btw, I assume that I have to calculate this much bytes:

2048 bytes to the power of 255 - number of bytes that is the same everywhere in the whole part. That will still leave many bytes to do.

MathieulH

For the first part in your answer, see above. For the second part, indeed, it could be hard coded in the die. Maybe Sony gets some paper that says that Syscon-chip & motherboard with number this has PSP Unique ID XXYYZZ. If it really happens that way, then we can assume that regeneration with that PSP Unique ID will never happen unless we find some leaked company secret documents. Unless we can look inside the factory where they build the PSP, we can only speculate on it. Have written that, I do agree with you on that point.

I hope that you guys/girls can find a way around it.

2048 bytes to the power of 255

Huh? How are you getting this calculation? If you think bruteforcing 2048 bytes is that many combinations you are way way way waaaaaay off.

2048^255 = 2.4 x 10^844

The real number of combinations is

2^(2048 x 8) = 1.2 x 10^4932

I dont think you realise just how big these numbers really are.

To put things in perspective:

The current generally accepted age of the universe is 13.7 billion years. In nanoseconds that is 4.3 x 10^26. Do you see the difference?

Now imagine you could check a combination each nanosecond (which you couldnt: assuming it takes one cycle to execute each instruction on the psp, it actually takes a few cycles, even running at 333MHz would take around 3ns to execute each instruction).

So if you started from the begininning of creation and checked one combination each nanosecond until the present day, you would have only bruteforced a little over 88 bits, thats 11 bytes !

Now think about bruteforcing 2048 bytes (if the universe is still around when you're finished).

Ok, I hope that'll put an end to this "bruteforcing idstorage" and hope people appreciate what it takes to bruteforce anything over a couple of bytes (theres a reason why commercial entities still only use 128 bit keys and still consider it secure).

Bruteforcing (in this context) just does not make sense. What does make sense is looking at the umd controller itself, looking through the driver and its interface to gain a better understanding of what its doing.

Myself, I have pretty much given up on the umd. But there is a few things people can still try.

So, here is how things should work (emphasize heavily on the word 'should'):

- Two secret keys, a master key and a device key.
- Data is encrypted with the master key and stored onto the umd.
- Master key is encrypted with the device key and then also stored on the umd.
- Device key is encrypted with each psps unique id and then stored in idstorage.

So to decrypt:

- the encrypted master key is read off the umd
- decrypt the idstorage to a decrypted device key
- decrypted device key decrypts the encrypted master key
- decrypted master key decrypts the data on the umd

All of this is done internally where no software can access. There maybe also be multiple master keys on the umd (for different sectors of the umd?), and hence multiple device keys.

Now for things for people to try, dump the umd controller firmware (though I havent been successful in doing so). I did manage to dump something that I thought was the firmware, but turned out it was just the internal umd read buffer (a 480KB buffer - a pretty standard size in DVD readonly drives). So what was dumped was the raw encrypted stream directly from the umd disc (all of it was encrypted except a small bit of plaintext - a bunch of sony copyright strings in pretty much every language as well as the umd game id UCAS-xxxxx or whatever).

To gain access to this part of the controller you need to enter the drives debug mode. Fortunately, the updaters do this for you since (for reasons unknown) it updates the drives debug code. You'll need the testmode.prx from an updater.

In debug mode, only debug commands can be executed, all other atapi commands fail. So I am hopeful for a way to dump the umd fw this way and gain a little more insight. But for now I have stopped.

SilverSpring,

Indeed, maybe my calculation is a bit off. That is okay. Writing the code is important for me. The rest is just second. Like I wrote several times before. It is a study object for me. I am not going to run this code forever.

Btw, good luck in try to dump that firmware. I really hope you succeed.

may I remind everyone that idstorage keys do not only allow the decryption of UMD data but also features such as openpsid or magicgate.

2048 bytes to the power of 255


Ok, now I see how you were trying to calculate but it is the wrong way.

It's actually 256^2048, though that still equals the same as what I wrote earlier, 2^(2048 x 8). They both equal to 1.2 x 10^4932.

Each byte has 256 values, there are 2048 bytes so 256^2048 = 1.2 x 10^4932

OR

Each bit has 2 values, there are 2048 bytes which are 8 bits each so 2^(2048 x 8) = 1.2 x 10^4932

Either way,


maybe my calculation is a bit off

is a huge understatement. A few years to bruteforce? Yes, it'll take a few years (+/- a few trillion trillion trillion trillion trillion trillion).

Just to appreciate how incredibly ridiculously large this number is here is some more perspective:

The total number of atoms in the universe is generally accepted to be somewhere between 1 x 10^78 to 1 x 10^80.

I think Jachra has conceded the point that he wont be able to brute force the master key (if not please delete your account and never come back). What he is interested in doing is going through the excercise of writing the code (maybe someday he will figure out how to massively overclock his PSP and complete the brute force in record time). Jachra, thats great and I hope you have a great time coding, but your posts no longer have anything to do with ID-Storage, so please move them someplace else as I hate checking the boards and finding drama instead of information.

Saben, thank you for your kind words.

I know it has little to with the ID Storage Discussion, but the way that people commented on me, I had no choice than to explain myself what I am trying to do.

is a huge understatement. A few years to bruteforce? Yes, it'll take a few years (+/- a few trillion trillion trillion trillion trillion trillion).

Just to appreciate how incredibly ridiculously large this number is here is some more perspective:

The total number of atoms in the universe is generally accepted to be somewhere between 1 x 10^78 to 1 x 10^80.

SilverSpring, my program IS NOT about doing a brute force attack at all.
It can do that, but that is not the main reason I am creating it. Sigh.

I like to create reusable code. I have been doing that for a very long time now. This program is teaching me how to hook on to firmware, how to create and load as a prx, learn how I can talk specific hardware in the PSP and some graphic stuff. That is all.

You can help me with that if you know if there is something like a programmers command code reference manual for the PSP sdk.

Added:

I will no longer comment on what I am trying to do and explaining it in several post in this thread.

To gain access to this part of the controller you need to enter the drives debug mode. Fortunately, the updaters do this for you since (for reasons unknown) it updates the drives debug code. You'll need the testmode.prx from an updater.


So the sce updaters do update the UMD drive firmware? Is this related to why 1.XX can't read/dump 2.80+ UMD Video/Music discs?

i have read all the threads is it possible to restore your id storage from a flash 0 back up.
i have been without a umd for a few days im only able to play homebrew through IR Shell with the autobooting plugin on, yet the adhoc mode dont work. (sorry for the noob question)

i have read all the threads is it possible to restore your id storage from a flash 0 back up.
i have been without a umd for a few days im only able to play homebrew through IR Shell with the autobooting plugin on, yet the adhoc mode dont work. (sorry for the noob question)

If you have a backup of your own flash (NAND-chip), then yes, it is possible.

SilverSpring, my program IS NOT about doing a brute force attack at all.
It can do that, but that is not the main reason I am creating it. Sigh.

You only say this now after you've been told multiple times that bruteforcing is not a viable option, but that was not what you've been originally stating.

You want to learn how to hook the firmware? How to create a prx? How to create graphics?

None of which has anything to do with bruteforcing let alone idstorage let alone regeneration of idstorage.

If you wanted to learn about certain programming methods, make a new thread asking for help, ask how to hook a function, how to create a prx, how to create graphics etc.

Instead, you've posted in the idstorage regeneration thread talking about bruteforcing. None of the above is needed to bruteforce something. So of course people will tell you the reality of what it means to try to bruteforce that amount of bytes.


You can help me with that if you know if there is something like a programmers command code reference manual for the PSP sdk.


http://psp.jim.sh/pspsdk-doc/
Documentation of the pspsdk.


So the sce updaters do update the UMD drive firmware? Is this related to why 1.XX can't read/dump 2.80+ UMD Video/Music discs?

I've never heard anything like that before. What do you mean by 2.80+ UMD's? UMD's that have 2.80+ updaters in them?

i have read all the threads is it possible to restore your id storage from a flash 0 back up.
i have been without a umd for a few days im only able to play homebrew through IR Shell with the autobooting plugin on, yet the adhoc mode dont work. (sorry for the noob question)

No a flash0 backup wont help you at all. You will need a backup of the full nand dump. The idstorage is not stored in flash0.

[quote=Jachra;10538]
I've never heard anything like that before. What do you mean by 2.80+ UMD's? UMD's that have 2.80+ updaters in them?


I don't know if it was 2.50 or 2.80, but in fact UMD Video/Music discs, which require that firmware are unable to fully dump/browse with 1.XX firmware. Maybe there are just some prx's which got updated by sce, which allow to handle such UMDs.

Same here, never heard of anything even remotely like that before. What I have known all along is that games do require certain kernels to be able to run because the crypto for the system modules on the disk is not compatible with older keys.

hey guys, I don't know if the problem is the IdStorage but I always get the "unsupported prx type" when loading UMD's from XMB, however if I run UMD's from NervOS, it runs well.
Is it the IdStorage?

I'd try going to official firmware (downgrade with pandora/des.cem, then update with an updater eboot) and see if the problem persists.

maybe someday he will figure out how to massively overclock his PSP and complete the brute force in record time

Even if you (by some miracle) manage to overclock the Alegrex R4000 cpu to 3 Ghz or more (which is very unlikely to be doable) It'd still take a few trillion years to brute force.

hey guys, I don't know if the problem is the IdStorage but I always get the "unsupported prx type" when loading UMD's from XMB, however if I run UMD's from NervOS, it runs well.
Is it the IdStorage?

Are your settings in the Recovery menu setup properly?

I don't know if it was 2.50 or 2.80, but in fact UMD Video/Music discs, which require that firmware are unable to fully dump/browse with 1.XX firmware. Maybe there are just some prx's which got updated by sce, which allow to handle such UMDs.

Well MUSIC UMD's were only added in (IIRC) 1.52 so maybe any MUSIC UMD won't work in 1.50 (or 1.00). VIDEO UMD's have (IIRC) always been supported but codecs had been added in later firmware so that might have something to do with it. I don't have any MUSIC UMD's to test but I'll try a VIDEO UMD on 1.00.

What happens exactly, it gives errors? Sounds very strange though.

maybe someday he will figure out how to massively overclock his PSP and complete the brute force in record time

Even if you (by some miracle) manage to overclock the Alegrex R4000 cpu to 3 Ghz or more (which is very unlikely to be doable) It'd still take a few trillion years to brute force.

Besides which, if the AC Adapter were to lose power, the battery would last for about 3 seconds :D

Thanks coy but this PSP is weird lol, it hasn't been working since the beginning of this month, I tried it again today and it worked, WTF?
Yesterday wasn't.

maybe someday he will figure out how to massively overclock his PSP and complete the brute force in record time

Even if you (by some miracle) manage to overclock the Alegrex R4000 cpu to 3 Ghz or more (which is very unlikely to be doable) It'd still take a few trillion years to brute force.

Besides which, if the AC Adapter were to lose power, the battery would last for about 3 seconds :D


1st, I wasnt serious but you can never fully discount hardware advances. But I could see someone implementing a flux capacitor along with a portable fusion power generator to develop a temporal disturbance that would allow the CPU to travel back in time so that it appears to finish instantaneously. :D

Well MUSIC UMD's were only added in (IIRC) 1.52 so maybe any MUSIC UMD won't work in 1.50 (or 1.00). VIDEO UMD's have (IIRC) always been supported but codecs had been added in later firmware so that might have something to do with it. I don't have any MUSIC UMD's to test but I'll try a VIDEO UMD on 1.00.

What happens exactly, it gives errors? Sounds very strange though.


If you browse the UMD in 1.XX you won't find any CLIPINFs STREAMs or RESOURCEs. Just the common UMD_DATA.BIN, updater and icons. In 2.XX however you will find them.

EDIT:
I don't think sce is updating the UMD drive, since the 1.50 firmware in time machine isn't able to browse the umd either (PSP was updated to 2.71 [which the UMD Video requires] before).

Thanks coy but this PSP is weird lol, it hasn't been working since the beginning of this month, I tried it again today and it worked, WTF?
Yesterday wasn't.
Yeah, you might want to consider what was mentioned above, recovery menu settings - if I remember right the plain modules and boot.bin settings can do some weird things, and using isofs driver on umd may also contribute. Either which way I doubt it is idstore that is the issue (which brought the suggestion to go to clean offical firmware and see if the problem persists, to test whether idstore or something else is causing the problem.)

The Isofs was not the problem, I tried Normal, Isofs, Sony NP9660 and M33 Driver, always the same error.

maybe someday he will figure out how to massively overclock his PSP and complete the brute force in record time

Even if you (by some miracle) manage to overclock the Alegrex R4000 cpu to 3 Ghz or more (which is very unlikely to be doable) It'd still take a few trillion years to brute force.

Besides which, if the AC Adapter were to lose power, the battery would last for about 3 seconds :D

3 ? xD You are pretty generous :P I'd say less than one xD

3 ? xD You are pretty generous :P I'd say less than one xD

I would pay to see an Allegrex overclocked to 3ghz... Rather, the smouldering remains, of an Allegrex overclocked to 3ghz. :D

Well, the proper way is to do it with extreme cooling. I bet we could gather around it and sing: "Ice, Ice, Baby". ;)

Yesterday, I had some strange experience. I had to install CF on a brand new Slim. I took it out of the box, inserted the Magic Memorystick (which contained Jas0nuk's menu and DC4, amongst some other tools) and popped in the battery.

The lights turned on, the PSP booted the menu and then I wasn't able to do anything because all keys where dead. Tried some more things, some other memorysticks but still the keys where dead.

Then I popped in a TM stick and tried to boot it. It didn't boot to internal fw but instead locked up. After rebooting to 1.50+3.40HW, the PSP did boot to the time/date entry part, but then again refused to do anything becaue the keys where still dead.

I decided to insert an unmodded battery. The PSP booted fine, although it took pretty long before anything showed up on the screen. Noticeably longer than after a "restore default". Entered time/date/timezone and so (the keys where working this time) and the XMB showed up.

After that, I was perfectly able to use the Magic Memorystick with the Pandora battery to install CF on the PSP.

All this makes me think that indeed the final initialization of the PSP is done at the first boot (as discussed before) and not in the factory!

It would be interesting to have a dump of the full memory of a PSP that has never been powered on. But to do so, we need a special dump tool which doesn't wait for any key to be pressed (since the keys aren't working at that time). And probably doesn't rely too much on information present in the PSP because that could still be uninitialized.

BTW. the PSP was a brand new Dutch piano black model and after booting with the unmodded battery, showed firmware version 3.80. So probably it is one of the latest series, although I didn't test battery creation on it.

All this makes me think that indeed the final initialization of the PSP is done at the first boot (as discussed before) and not in the factory!

It would be interesting to have a dump of the full memory of a PSP that has never been powered on.

Ah! I said the same exact thing a few weeks back when I got a new slim. Was annoyed I didnt do a nand dump before first turning it on (I did one straight after though).

Yea I noticed too that on first power on things took a lot longer to boot, thought it was bricked at first because it was just a blank screen (yes longer than the time it takes on restoring default settings). But all subsequent boots were at normal speed again.

So something's definitely happening on first boot. But I do think it's only on newer psp's (or newer fw rather), I dont remember this happening on any of the older psp's I had.

Mine was a 3.72 Felicia Blue JP model.

EDIT:
Yea a nand dump before any code on the nand gets run would be good. Lately, they have liked doing things like self-deleting code and stuff like that.

Could it be that Nand comes empty from factory and first run writes all the values that it needs to work properly?
If so maybe adding a function to nandtool to fully erase nand and installing OFW afterwords would maybe do the same as first run?

Just a thought.

It would be interesting to have a dump of the full memory of a PSP that has never been powered on.
You know, someone contacted me with this very problem last week or so (regarding a fat PSP IIRC), so I whipped up a program that does no prompt dumping - in that PSP's case though it had been working fine before, but apparently messing around with keycleaner or flash1 cleaner or some such thing caused the buttons to stop working. May suggest syscon is open to writes long after manufacture, or that one of the idstore keys is boot-time critical to digital keys working (the guy hasn't gotten back to me since I forwarded the app, go figure.)

Nevertheless, the elf is attached, it is open nanddumper sans keypressing. All it uses are NAND functions which shouldn't rely too heavily on any per PSP info.

edit:/ going back to what was said about a strange ipl fragment, is it possible an initial IPL does all this type of work to write keys that would make syscon function to provide key input, which then overwrites itself with the true IPL? If not I'd gladly flash back my original NAND dumps and start digging for file fragments. Then again, maybe I'm just being gullible on that one day of the year I shouldn't be xD

edit2:/ added source code to the app zip

If needed I can buy a brand new psp in the Netherlands and try to get such dump.

If needed I can buy a brand new psp in the Netherlands and try to get such dump.

That would be very helpful :)

Thank you, Mathieulh, consider it done.

All I need is Dark_AleX's Despertar del Cementerio, Jasonuk's Elfmenu and Cory1942's dumper, memstick and a Pandora battery, right?

/edit
Cory1942,

I will change your source so that it makes a logfile of anything that is written to the screen also. The changed code will be posted here.

Hum... as far as I know of, the DCv5 (and DCv4) does not need any idstorage keys to run but I may be wrong, and it does feature a nand dumper function.

Well MUSIC UMD's were only added in (IIRC) 1.52 so maybe any MUSIC UMD won't work in 1.50 (or 1.00). VIDEO UMD's have (IIRC) always been supported but codecs had been added in later firmware so that might have something to do with it. I don't have any MUSIC UMD's to test but I'll try a VIDEO UMD on 1.00.

What happens exactly, it gives errors? Sounds very strange though.


If you browse the UMD in 1.XX you won't find any CLIPINFs STREAMs or RESOURCEs. Just the common UMD_DATA.BIN, updater and icons. In 2.XX however you will find them.

EDIT:
I don't think sce is updating the UMD drive, since the 1.50 firmware in time machine isn't able to browse the umd either (PSP was updated to 2.71 [which the UMD Video requires] before).

Ok in that case it's definitely an issue with the psp fw and nothing to do with the umd drive. The updaters definitely update the umd drive but (it seems) only for those very early 1.00 JP models. But since all updaters need to work on even 1.00, it's been included with every updater since. Also downgrading your psp fw doesnt do anything to the umd drive.

Anyway, if anyone's interested here's an app to check your UMD FW version (3.xx app + source):

http://silverspring.lan.st/umd_ver_check.rar

and link to blog entry http://my.malloc.us/silverspring/2008/04/02/umd-firmware-version-checker/

Well MUSIC UMD's were only added in (IIRC) 1.52 so maybe any MUSIC UMD won't work in 1.50 (or 1.00). VIDEO UMD's have (IIRC) always been supported but codecs had been added in later firmware so that might have something to do with it. I don't have any MUSIC UMD's to test but I'll try a VIDEO UMD on 1.00.

What happens exactly, it gives errors? Sounds very strange though.


If you browse the UMD in 1.XX you won't find any CLIPINFs STREAMs or RESOURCEs. Just the common UMD_DATA.BIN, updater and icons. In 2.XX however you will find them.

EDIT:
I don't think sce is updating the UMD drive, since the 1.50 firmware in time machine isn't able to browse the umd either (PSP was updated to 2.71 [which the UMD Video requires] before).

Ok in that case it's definitely an issue with the psp fw and nothing to do with the umd drive. The updaters definitely update the umd drive but (it seems) only for those very early 1.00 JP models. But since all updaters need to work on even 1.00, it's been included with every updater since. Also downgrading your psp fw doesnt do anything to the umd drive.

Anyway, if anyone's interested here's an app to check your UMD FW version (3.xx app + source):

http://silverspring.lan.st/umd_ver_check.rar

and link to blog entry http://my.malloc.us/silverspring/2008/04/02/umd-firmware-version-checker/


Is it done by leptonupdater103 ? Does it update the whole firmware or only the debug codes ?

Thank you, Mathieulh, consider it done.

All I need is Dark_AleX's Despertar del Cementerio, Jasonuk's Elfmenu and Cory1942's dumper, memstick and a Pandora battery, right?

/edit
Cory1942,

I will change your source so that it makes a logfile of anything that is written to the screen also. The changed code will be posted here.
Apparently the keys (you know, the buttons you would press to make things happen in programs like elf menu or des.cem) don't work until you boot official firmware once - so what you'll have to do is with des.cem, replace resurrection.elf with the dumper so it runs and dumps right off the get-go without pressing any keys at all. If you boot it even only once before dumping to get keys working, the experiment would have useless results.

Feel free to change the source however you like, the only thing put to the screen is status messages and info like "bad block @", so I don't see how a log of that would even be useful. Then again, maybe to be thorough also change the source to dump the contents of bad blocks as well, instead of skipping them (and just writing 0xFF filled buffer to disk) like it currently does.

Is it done by leptonupdater103 ? Does it update the whole firmware or only the debug codes ?

Yea the leptonupdater.

Yes it doesnt update the whole firmware only the debug codes, but it uses the firmware version to determine what to update.

It will only update if fw version is 1.020 or 1.090 (with different debug codes depending if you have 1.020 or 1.090). So only the very early model umd drives get updated.

I have a 1.00 JP model which was v1.090, a ceramic white TA-082 which was v1.150, and a new slim bought a few weeks back which was v1.240.

Havent figured out much about the debug codes mainly because the format looks encrypted and is only 640 Bytes in total. But it seems to control what debug commands are available to use when in debug mode.

EDIT:


Apparently the keys (you know, the buttons you would press to make things happen in programs like elf menu or des.cem)

LOL, yea you have to be careful by what you mean by "keys" especially in this thread :p.

It will only update if fw version is 1.020 or 1.090 (with different debug codes depending if you have 1.020 or 1.090). So only the very early model umd drives get updated.


Will the leptonupdater increase the version number?
My early JP PSP unit (first batch of 1.50 units) comes with 1.090 and still appears to have version 1.090 after updating to 3.93.

EDIT: EU Ceramic White PSP which came with 2.60_2 shows the same phenomenon (1.090).

EDIT2: Well... seems like I just have 1.090 UMD drives.. (CW JP 2.00 release PSP has got it too)

Yesterday, I had some strange experience. I had to install CF on a brand new Slim. I took it out of the box, inserted the Magic Memorystick (which contained Jas0nuk's menu and DC4, amongst some other tools) and popped in the battery.

The lights turned on, the PSP booted the menu and then I wasn't able to do anything because all keys where dead. Tried some more things, some other memorysticks but still the keys where dead.

Then I popped in a TM stick and tried to boot it. It didn't boot to internal fw but instead locked up. After rebooting to 1.50+3.40HW, the PSP did boot to the time/date entry part, but then again refused to do anything becaue the keys where still dead.

I decided to insert an unmodded battery. The PSP booted fine, although it took pretty long before anything showed up on the screen. Noticeably longer than after a "restore default". Entered time/date/timezone and so (the keys where working this time) and the XMB showed up.

After that, I was perfectly able to use the Magic Memorystick with the Pandora battery to install CF on the PSP.

All this makes me think that indeed the final initialization of the PSP is done at the first boot (as discussed before) and not in the factory!

It would be interesting to have a dump of the full memory of a PSP that has never been powered on. But to do so, we need a special dump tool which doesn't wait for any key to be pressed (since the keys aren't working at that time). And probably doesn't rely too much on information present in the PSP because that could still be uninitialized.

BTW. the PSP was a brand new Dutch piano black model and after booting with the unmodded battery, showed firmware version 3.80. So probably it is one of the latest series, although I didn't test battery creation on it.

That is unusual.

A week or two ago, I downgraded a Piano black PSP-2000 in North America right out of the box, and I remember being able to dump the psp with DCv4 without having booted the psp prior to taking it out of the box (I remember this cause we had to use a swiss army knife to get it out, stupid guy forgot to bring exacto knife)

Is that the sort of dump we're discussing? PSP before a first boot into the XMB?

gusto05, the answer is yes.

SilverSpring, nice to see you still involved with the PSP, we've been noticing your absence on IRC lately, I assume you've had a lot of work on :)

This is starting to get interesting. I wonder why the keys don't work until the first time official firmware is run... doesn't syscon manage those? To me, that suggests that syscon isn't fully activated until the IPL runs for the first time, so the factory IPL is a special one, which does whatever it does, then overwrites itself with the official firmware IPL. Hopefully when we get a NAND dump of a brand new PSP, we'll know for sure. :p

If I get a nand dump from a never bootup psp can i post it here or is it illegal?

It's Illegal you can always send me a PM though :P

It will be yours tomorrow through a pm to me.

/edit
added the changed source from cory1942

/re-edit

For the source, see page 42 (http://lan.st/showpost.php?p=10672&postcount=412)

It will be yours tomorrow through a pm to me.

/edit
added the changed source from cory1942

I won't be able to get until next week so if you could send me a pm with your, much apreciated :P

Ran Silverspring's UMD version checker on my pair of PSP-100x units

US one (TA-081) got:

00000000 05 80 00 32 5C 00 00 00 53 43 45 49 20 20 20 20 .€.2...SCEI
00000010 55 4D 44 20 52 4F 4D 20 44 52 49 56 45 20 20 20 UMD ROM DRIVE
00000020 20 20 20 20 31 2E 30 39 30 20 4F 63 74 31 38 20 1.090 Oct18
00000030 2C 32 30 30 34 20 20 20 00 00 00 00 00 00 00 00 ,2004 ........
00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

JP one (TA-086) got :
Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F

00000000 47 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 G...............
(all zeroes to the end)

Am I doing anything wrong ? (lol)

I was expecting the TA-086 to have the same firmware as TA-082 since TA-086 uses the same media engine/alegrex chip pair. But I got an empty file... Anything new here ?

Dump is done.

From where to where is the ipl located in the dump?

I have spoken with Mathieulh on irc and he told me that it contains a 3.80 IPL.

The IPL is located at 0x40000.

By the way I just inspected a nand dump from a psp that has never been turned on and the IPL is just the retail 3.80 IPL, so unless the initialisation is done from some place else than the nand (perhaps code running inside syscon) I don't believe there can be anything done on the psp outside factory at first boot.

As I said to Math before, this still doesn't explain why buttons dont work until the first official firmware boot. Something in Syscon needs to be activated outside the factory, methinks. :/

Maybe it is the power up that is enough or a special prx.

Maybe it is the power up that is enough or a special prx.


A prx needs to be loaded by a kernel, considering the 3.80IPL is in there I don't see how any special kernel could start to perform any initialisations.

Well, I was thinking of a prx that just gives the syscon a wake up call and then is removed.

I don't recall any unknown prx being in the 3.80's pspbtcnf.bin although who knows it could be overwritten although I highly doubt it

Well, maybe I am going to look if something is left in the empty spaces in that dump.
Maybe they first flash a special firmware to do something, wipe it and then install this firmware.

I remember reading a post that some found something in a NAND. Some trace of a file. But I am not sure where or who it was.

lflash is encrypted, beside I expect them to format it once it's done, so I doubt you will find anything.

Jachra,

It might be illuminating to have the unit do its first boot and then we could delta the two dumps. I would be interested in the state of the keys pre-1st boot and then post 1st boot. If we think we captured a dump prior to the keys being created then this would be real obvious in the delta between the pre/post 1st boot.

Jachra,

It might be illuminating to have the unit do its first boot and then we could delta the two dumps. I would be interested in the state of the keys pre-1st boot and then post 1st boot. If we think we captured a dump prior to the keys being created then this would be real obvious in the delta between the pre/post 1st boot.
Perhaps a no button press version (as with the no button press nand dump tool used here) of Nandtool's 0.3b dump idStorage keys could retrieve the keys from the unbooted unit. This way an unencrypted view of the keys could be more easily compared with the subsequent post bootup key dump?

That PSP is now running 3.80 M33 firmware. I could ask if to my friend, who owns it now, to make a new dump.
I can flash this dump in my PSP Slim and extract the keys unencrypted.

My first observation: Flashed all but IDStorage, then tried to boot - Screen doesn't turn on, power light comes on for a little less than a second, then shuts down.

My first observation: Flashed all but IDStorage, then tried to boot - Screen doesn't turn on, power light comes on for a little less than a second, then shuts down.

PRX files are signchecked. Since lflash is encrypted, you won't have any luck to run that dump on your PSP.

EDIT: Well.. since your power light doesn't last more than a second, could be something with IPL.. dunno.

My first observation: Flashed all but IDStorage, then tried to boot - Screen doesn't turn on, power light comes on for a little less than a second, then shuts down.

PRX files are signchecked. Since lflash is decrypted, you won't have any luck to run that dump on your PSP.
Signchecking cannot stop me!!

*looks at black screen*

...


*shuffles uncomfortably*

My first observation: Flashed all but IDStorage, then tried to boot - Screen doesn't turn on, power light comes on for a little less than a second, then shuts down.

Did you have your ID Storage in that flash?

Yeah, I was buzzed on caffeine. Anyway...

I dumped the keys - they're all full of crap, but are logical numbers, not like when you dump them when they're behind NAND encryption (0xEBC8 wut).

A whole bunch are missing - 5,6,10,100,101 at a glance.

Yeah, I was buzzed on caffeine. Anyway...

I dumped the keys - they're all full of crap, but are logical numbers, not like when you dump them when they're behind NAND encryption (0xEBC8 wut).

A whole bunch are missing - 5,6,10,100,101 at a glance.

Did you dump them in their decrypted form ?

Looks to me like they haven't decrypted properly, the magic number for your PSP returned by the function cory uses will not decrypt that NAND dump, as its from another PSP.

Looks to me like they haven't decrypted properly, the magic number for your PSP returned by the function cory uses will not decrypt that NAND dump, as its from another PSP.Could this dump not be flashed to the PSP in question and then the keys extracted using Nandtool 0.3b via key dump? (or is it too late for that).

It could be done tonight. Anyone how to setup it up?

OK... the only way I can think of doing this, is asking cory1492 to do a special version of nandTool which automatically dumps the keys on boot, so you flash the NAND dump to that PSP, then replace DC5's resurrection.elf with that new nandTool and let it dump the keys.

Well I could write a PC app that will decrypt the slim idstorage area from a nand dump, might be easier to do rather than doing flashing & reflashing etc on that specific PSP. This way also everyone can decrypt it too. The only thing that's needed is a specific id from the psp, so you'll need to run an app and dump the seed first.

OK... the only way I can think of doing this, is asking cory1492 to do a special version of nandTool which automatically dumps the keys on boot, so you flash the NAND dump to that PSP, then replace DC5's resurrection.elf with that new nandTool and let it dump the keys.That is what had crossed my mind, if Cory1492 is up for it naturally. This way the original keys could be decrypted. It would also be worth dumping the keys now that cfw has been applied using nandtool 0.3b before flashing back the original nand dump (for the sake of comparisson).

Could it be that the buttons will now work even if the original dump is flashed back? Perhaps whatever happens on first bootup that activates the buttons is permanent? It would be worth a try before Cory1492 goes to the trouble of producing a special version of nandtool.

edit: my post is superceeded by Silverspring's post above

Ok here's the app (it's 3.xx) you'll need to run on the psp that the dump came from. It'll print 2 numbers, this is the seed used to decrypt the nand. That is all that is needed, the actual encryption algorithm is pretty simple and can be done trivially on a PC.

Ok here's the app (it's 3.xx) you'll need to run on the psp that the dump came from. It'll print 2 numbers, this is the seed used to decrypt the nand. That is all that is needed, the actual encryption algorithm is pretty simple and can be done trivially on a PC.

Awesome! Thanks. This will save me a lot of time in future :)

Will the leptonupdater increase the version number?
My early JP PSP unit (first batch of 1.50 units) comes with 1.090 and still appears to have version 1.090 after updating to 3.93.


No, only updates debug code not the whole firmware, so version numbers stay the same (until you update whole umd firmware).

SilverSpring, nice to see you still involved with the PSP, we've been noticing your absence on IRC lately, I assume you've had a lot of work on :)


Indeed, to quote from blog comments:


Mr305: "No more tech stuff since past few weeks... :("

Me: "full-time study + part-time work + social life + family commitments + other hobbies + few other (non-psp) projects + illness these past few weeks = very little time indeed for pspdev"


Unfortunately, projects that matter in the real world take precedence over anything done for fun (ie. stuff that will get marked and go towards credits). But atm I have a bit of spare time so...here I am :).

Ran Silverspring's UMD version checker on my pair of PSP-100x units

US one (TA-081) got:

00000000 05 80 00 32 5C 00 00 00 53 43 45 49 20 20 20 20 .€.2...SCEI
00000010 55 4D 44 20 52 4F 4D 20 44 52 49 56 45 20 20 20 UMD ROM DRIVE
00000020 20 20 20 20 31 2E 30 39 30 20 4F 63 74 31 38 20 1.090 Oct18
00000030 2C 32 30 30 34 20 20 20 00 00 00 00 00 00 00 00 ,2004 ........
00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

JP one (TA-086) got :
Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F

00000000 47 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 G...............
(all zeroes to the end)

Am I doing anything wrong ? (lol)

I was expecting the TA-086 to have the same firmware as TA-082 since TA-086 uses the same media engine/alegrex chip pair. But I got an empty file... Anything new here ?

OoOo that is strange. Dont think Ive seen that happen before. Have you done anything unusual with that psp (like reflowed it or something like that lol)? That's quite interesting, it always dumps like that even running multiple times?

Well, maybe I am going to look if something is left in the empty spaces in that dump.
Maybe they first flash a special firmware to do something, wipe it and then install this firmware.

I remember reading a post that some found something in a NAND. Some trace of a file. But I am not sure where or who it was.

Yes it was actually in this very thread a few pages back :p: http://lan.st/showthread.php?p=9899

SilverSpring/Jachra: NandTool 03 Beta1 tells you the seed (under PSP Info) also.

Another thing for Cory to consider would be letting you enter your own seed for decrypting/dumping.

Cory1942 gave me a program to extract the decrypted keys from the PSP under Cem.
I am going to do that in the morning.

The ID of that PSP is:

0x14AD1488
0x00007930

The keys have been dumped with cory1942 key extractor tool. Also the keys of that PSP with CFW 3.90M33-3 have been dumped.

The ID of that PSP is:

0x14AD1488
0x00007930

The keys have been dumped with cory1942 key extractor tool. Also the keys of that PSP with CFW 3.90M33-3 have been dumped.

Okay... care to share anything about them? Some of us are very curious :D

I know brin_vg. I will package them and those who wants them, well, pm me.

I know brin_vg. I will package them and those who wants them, well, pm me.

Awesome :D

One thing makes me curious. The keys dumped from the virgin nand-dump contains a 1024 bytes index.bin-file. I have never seen that one before.

I just analysed the keys from the psp before and after it was turned on. They are all identical, we can conclude that whatever generates the idstorage keys has been run before first boot (probably at factory)

I just analysed the keys from the psp before and after it was turned on. They are all identical, we can conclude that whatever generates the idstorage keys has been run before first boot (probably at factory)
Dang about that thing I was thinking about :D

At least we know, now. Cheers Jachra :)

You are welcome, brin_vg.

I just analysed the keys from the psp before and after it was turned on. They are all identical, we can conclude that whatever generates the idstorage keys has been run before first boot (probably at factory)In that case it seems that we can exclude idStorage as having anything to do with why a new/unbooted unit takes longer to boot when first turned on (plus the fact that the buttons do not work initially).

Could the virgin ipl/flash0 throw any light on this issue?

I just analysed the keys from the psp before and after it was turned on. They are all identical, we can conclude that whatever generates the idstorage keys has been run before first boot (probably at factory)In that case it seems that we can exclude idStorage as having anything to do with why a new/unbooted unit takes longer to boot when first turned on (plus the fact that the buttons do not work initially).

Could the virgin ipl/flash0 throw any light on this issue?

The IPL and firmware are stock 3.80.

Darn, I had hopes that this could be something big. Let me see if I've got the facts correct. The problem was reported on:

Stock Slim, Dutch, 3.8, Piano Black by squirrel61
Stock Slim, JP, 3.72, Felicia Blue by Silverspring

Symptoms were that prior to factory 1st boot, button presses didn't register on pandora booted FWs. 1st boot took longer than usuall and then buttons worked.

Jachra bought a Stock Slim, Netherlands?, 3.8, ?color?

Dumped nand and examined keys and keys were identical between pre-first boot and post-first boot.

---

Jachra, do you remember if your unit exhibited the same button issue as the originally reported problem?

JP one (TA-086) got :

00000000 47 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 G...............
(all zeroes to the end)

Am I doing anything wrong ? (lol)


OoOo that is strange. Dont think Ive seen that happen before. Have you done anything unusual with that psp (like reflowed it or something like that lol)? That's quite interesting, it always dumps like that even running multiple times?


Actually no. It's a late 2006/early 2007 japanese CW TA-086. Hardware wise it's virgin.

Ok ...
But, then earlier today I tried the software on an customer's PSP (TA-079) and got this:

00000000 48 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 H...............

Pretty suspicious. Took the Ceramic White PSP, fired up my DC stick, dumped my FW (for restoring later as I have a ton of customizations) and reinstalled 3.71M33.

Result:

00000000 05 80 00 32 5C 00 00 00 53 43 45 49 20 20 20 20 ...2...SCEI
00000010 55 4D 44 20 52 4F 4D 20 44 52 49 56 45 20 20 20 UMD ROM DRIVE
00000020 20 20 20 20 31 2E 31 35 30 41 41 75 67 33 30 20 1.150AAug30
00000030 2C 32 30 30 35 20 20 20 00 00 00 00 00 00 00 00 ,2005 ........
00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ As expected.

Now, I believe it's the PSP firmware (3.90) what caused the weird results. Might it be that the firmware is stored in one of the PRXs, just like the wireless lan hardware ?

Jachra bought a Stock Slim, Netherlands?, 3.8, ?color?

Jachra, do you remember if your unit exhibited the same button issue as the originally reported problem?

A1. Silver version

A2. No, it did not.

/edit
The dumping was done with a DCEM4 memstick. I only modified to enable the tools supplied by cory1942.

One thing makes me curious. The keys dumped from the virgin nand-dump contains a 1024 bytes index.bin-file. I have never seen that one before.

Did you compare the bigger index.bin with the smaller index.bin to see what is diferent and what was added? There could be some thing that could make the diference. :eek:

One thing makes me curious. The keys dumped from the virgin nand-dump contains a 1024 bytes index.bin-file. I have never seen that one before.

Did you compare the bigger index.bin with the smaller index.bin to see what is diferent and what was added? There could be some thing that could make the diference. :eek:


Erm, I am lost. I wrote that I haven't seen it before. This is the first time I ever saw it.

/re-edit

Added the update source from cory1942.
Still one bug to fix. scePowerRequestStandby doesn't seem to shutdown the PSP in Pandora. If you have a solution, please let me know.

index.bin is the same dumped by nandTool or Dark_Alex's nandflasher, it is just the 2 pages of index data which is basically like LBA data, maps where keys are physically in the NAND.

Use sceSysconPowerStandby() instead, demanding power off instead of asking nicely for it seems to work fine for me (scePowerRequestStandby sounds like it may rely on a callback or something.)

cory1942, thank you for that information.

SilverSpring/Jachra: NandTool 03 Beta1 tells you the seed (under PSP Info) also.

Oh ok, guess I should've known since that part would be my code :p. Nvm that app I posted then ;).




Ok ...
But, then earlier today I tried the software on an customer's PSP (TA-079) and got this:

00000000 48 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 H...............

Pretty suspicious. Took the Ceramic White PSP, fired up my DC stick, dumped my FW (for restoring later as I have a ton of customizations) and reinstalled 3.71M33.

Result:

00000000 05 80 00 32 5C 00 00 00 53 43 45 49 20 20 20 20 ...2...SCEI
00000010 55 4D 44 20 52 4F 4D 20 44 52 49 56 45 20 20 20 UMD ROM DRIVE
00000020 20 20 20 20 31 2E 31 35 30 41 41 75 67 33 30 20 1.150AAug30
00000030 2C 32 30 30 35 20 20 20 00 00 00 00 00 00 00 00 ,2005 ........
00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ As expected.

Now, I believe it's the PSP firmware (3.90) what caused the weird results. Might it be that the firmware is stored in one of the PRXs, just like the wireless lan hardware ?

Ah well I only tested that app on 3.52M33 & 3.71M33 so I guess maybe not compatible with 3.90M33. Yea its probably not a PSP problem but problem with the app.


Well, maybe I am going to look if something is left in the empty spaces in that dump.
Maybe they first flash a special firmware to do something, wipe it and then install this firmware.

I remember reading a post that some found something in a NAND. Some trace of a file. But I am not sure where or who it was.

Well actually turned out to be the same as on the original 3.60 dumps but this time many more blocks got leftover, though still not enough to have a fully decrypted payload. On the 3.60 dump only 6 blocks of the factory IPL were leftover, in the 3.80 dump there are 22 blocks altogether leftover:

Last 22 blocks of Factory IPL

loadaddr blocksize entry checksum
0x04116480 0xF50 0 0xDF6CEDF5
0x041173D0 0xF50 0 0x4457DE64
0x04118320 0xF50 0 0xE4D5F74C
0x04119270 0xF50 0 0xCF0D84BE
0x0411A1C0 0xF50 0 0xF77FD68B
0x0411B110 0xF50 0 0xE33931E5
0x0411C060 0xF50 0 0xD9183486
0x0411CFB0 0xF50 0 0x66094E77
0x0411DF00 0xF50 0 0xEE3C931B
0x0411EE50 0xF50 0 0xBF0DA9E8
0x0411FDA0 0xF50 0 0x63F76F01
0x04120CF0 0xF50 0 0x64251D97
0x04121C40 0xF50 0 0x1D64B821
0x04122B90 0xF50 0 0x50BBBE38
0x04123AE0 0xF50 0 0x2C4C33A3
0x04124A30 0xF50 0 0x51FAF2BE
0x04125980 0xF50 0 0x729D1DC0
0x041268D0 0xF50 0 0x39C3A1D7
0x04127820 0xF50 0 0x572B030C
0x04128770 0xF50 0 0x7B8E52F8
0x041296C0 0xF50 0 0x0462AFB0
0x0412A610 0x210 0x040F0000 0x331B9575

All 22 blocks decrypted ok but that still wasnt enough to get the complete encrypted payload. Judging from the massive size of the factory IPL we would need at least double that to get the full payload. Also this factory IPL hasnt changed either since the last 6 blocks here matches the 6 of the 3.60 Factory IPL blocks. So it's probably a standard factory firmware that flashes the actual retail firmware over it and probably similar to the service center jigkick firmware.

But even if we got the full factory IPL I doubt it has the code to regenerate the idstorage, if you look at the leaked jigkick firmware, there is an "id" folder which has individual idstorage keys in there. So the jigkick would probably just flash the individual keys it finds in that folder rather than generating the keys itself. But that must also mean that the individual keys are being generated somewhere and then copied to the "id" folder for the jigkick to flash. So the jigkick just looks like a generic flasher and nothing else, flashing whatever psar & idstorage keys it finds on the memstick. I guess there could be another app that will generate the keys seperately for jigkick flasher usage.

But that must also mean that the individual keys are being generated somewhere and then copied to the "id" folder for the jigkick to flash. So the jigkick just looks like a generic flasher and nothing else, flashing whatever psar & idstorage keys it finds on the memstick. I guess there could be another app that will generate the keys seperately for jigkick flasher usage.

Sounds like an awfully unautomated/unproductive way of doing it. Doing that for every single PSP made... just doesn't sound very efficient.

But that must also mean that the individual keys are being generated somewhere and then copied to the "id" folder for the jigkick to flash. So the jigkick just looks like a generic flasher and nothing else, flashing whatever psar & idstorage keys it finds on the memstick. I guess there could be another app that will generate the keys seperately for jigkick flasher usage.

Sounds like an awfully unautomated/unproductive way of doing it. Doing that for every single PSP made... just doesn't sound very efficient.

Indeed, but only because it was never designed for this. The retail updaters do not touch the idstorage area at all, only the IPL and lflash. So their service centers would be designed to only fix IPL+lflash corruption from power being cut during an ofw update.

The heavily encrypted jigkick firmware suggests that not even service centers could be trusted. Only headquaters would have the encryption keys and have the ability to create those prx's, psar's, & idstorage keys that it supplies to the service centers on these heavily encrypted memsticks. So if they needed to fix something like idstorage corruption I would suspect it would have to get new idstorage keys generated back from headquaters since only they would have the encryption keys (and only they could be trusted). Since normal service center usage would only ever need to deal with IPL & flash updates (before homebrew - and noobs - came along and started destroying their entire nands with no nand backups).

Jachra bought a Stock Slim, Netherlands?, 3.8, ?color?

Jachra, do you remember if your unit exhibited the same button issue as the originally reported problem?

A1. Silver version

A2. No, it did not.

/edit
The dumping was done with a DCEM4 memstick. I only modified to enable the tools supplied by cory1942.
If with your A2 you meant that you didn't notice the button malfunctioning (meaning that you where able to press buttons and the PSP was reacting on that), that would mean there are two kinds of "virgin" states for the PSP.

One of that states would be "full virgin" with the behaviour Silverspring and I noticed and the other state would probably be "factory pre-powered-on", in which case the first initialization has been done by first time powering-on the PSP in the factory already (probably part of a checkup or burn in test).

Whenever I can lay my hands on another brand-new PSP, I'll create all possible dumps (straight from the box, after first power-on and after CFW installation).

Perhaps add a small delay and simple button test to the start of the dumper program :D

Jachra bought a Stock Slim, Netherlands?, 3.8, ?color?

Jachra, do you remember if your unit exhibited the same button issue as the originally reported problem?

A1. Silver version

A2. No, it did not.

/edit
The dumping was done with a DCEM4 memstick. I only modified to enable the tools supplied by cory1942.
If with your A2 you meant that you didn't notice the button malfunctioning (meaning that you where able to press buttons and the PSP was reacting on that), that would mean there are two kinds of "virgin" states for the PSP.

One of that states would be "full virgin" with the behaviour Silverspring and I noticed and the other state would probably be "factory pre-powered-on", in which case the first initialization has been done by first time powering-on the PSP in the factory already (probably part of a checkup or burn in test).

Whenever I can lay my hands on another brand-new PSP, I'll create all possible dumps (straight from the box, after first power-on and after CFW installation).

Correct, I was able to press the buttons easily and the PSP reacted well on it.

Well actually turned out to be the same as on the original 3.60 dumps but this time many more blocks got leftover, though still not enough to have a fully decrypted payload. On the 3.60 dump only 6 blocks of the factory IPL were leftover, in the 3.80 dump there are 22 blocks altogether leftover:

Last 22 blocks of Factory IPL

loadaddr blocksize entry checksum
0x04116480 0xF50 0 0xDF6CEDF5
0x041173D0 0xF50 0 0x4457DE64
0x04118320 0xF50 0 0xE4D5F74C
0x04119270 0xF50 0 0xCF0D84BE
0x0411A1C0 0xF50 0 0xF77FD68B
0x0411B110 0xF50 0 0xE33931E5
0x0411C060 0xF50 0 0xD9183486
0x0411CFB0 0xF50 0 0x66094E77
0x0411DF00 0xF50 0 0xEE3C931B
0x0411EE50 0xF50 0 0xBF0DA9E8
0x0411FDA0 0xF50 0 0x63F76F01
0x04120CF0 0xF50 0 0x64251D97
0x04121C40 0xF50 0 0x1D64B821
0x04122B90 0xF50 0 0x50BBBE38
0x04123AE0 0xF50 0 0x2C4C33A3
0x04124A30 0xF50 0 0x51FAF2BE
0x04125980 0xF50 0 0x729D1DC0
0x041268D0 0xF50 0 0x39C3A1D7
0x04127820 0xF50 0 0x572B030C
0x04128770 0xF50 0 0x7B8E52F8
0x041296C0 0xF50 0 0x0462AFB0
0x0412A610 0x210 0x040F0000 0x331B9575

All 22 blocks decrypted ok but that still wasnt enough to get the complete encrypted payload. Judging from the massive size of the factory IPL we would need at least double that to get the full payload. Also this factory IPL hasnt changed either since the last 6 blocks here matches the 6 of the 3.60 Factory IPL blocks. So it's probably a standard factory firmware that flashes the actual retail firmware over it and probably similar to the service center jigkick firmware.

But even if we got the full factory IPL I doubt it has the code to regenerate the idstorage, if you look at the leaked jigkick firmware, there is an "id" folder which has individual idstorage keys in there. So the jigkick would probably just flash the individual keys it finds in that folder rather than generating the keys itself. But that must also mean that the individual keys are being generated somewhere and then copied to the "id" folder for the jigkick to flash. So the jigkick just looks like a generic flasher and nothing else, flashing whatever psar & idstorage keys it finds on the memstick. I guess there could be another app that will generate the keys seperately for jigkick flasher usage.

First, a very nice find. :D
Perhaps with a lot of virgin dumps we might pierce together that IPL. However, it would take long time to do so.

In the leaked jigkicks that I found, only a empty parental_lock.bin was there, but you could be very right in your assumption. I guess they have a internal application or email for requesting those keys from HQ. After that they could be send through internal email or placed on a share.

The other way a service center could request those keys if they replaced the motherboard with a new one. That new one should then have a empty NAND. It would be most likely that just a few persons on such service center is able to request those keys at all.

/edit

Just a thought. As far as I know, most of us think that the PSP Unique ID is only somewhere inside the syscon-chip. Has anyone checked if it is also something on his PSP motherboard?

In the leaked jigkicks that I found, only a empty parental_lock.bin was there, but you could be very right in your assumption.


Well it's not empty (has a byte 0x09 in it). If you look, you'll see that it's the same as the key 0x47 in idstorage, which does happen to be the default parental lock param key.

I have access to roughly 52 nand-dumps mostly from ofw before modding them. 1 or 3 of them are from already modded psp's...

all dumps are from both slim and phat's from all different firmwares.

Let me know if you want them....I don't know how much use they will be but...your more then welcome to them..

send me a pm or hit me on max console I'm not always on here.

That is a very nice offer, Erland. I hope that SilverSpring will contact you.

I have access to roughly 52 nand-dumps mostly from ofw before modding them. 1 or 3 of them are from already modded psp's...

all dumps are from both slim and phat's from all different firmwares.

Let me know if you want them....I don't know how much use they will be but...your more then welcome to them..

send me a pm or hit me on max console I'm not always on here.

Thats at least 1.7GB (3.4GB for slim dumps)!! How are you going to share them :confused:????

Thats at least 1.7GB (3.4GB for slim dumps)!! How are you going to share them :confused:????

I will share them magically over the internet....how else....snail mail? I have a dedicated server at my job just for webhosting.....I also have 1TB on my ftp...

Trust me sharing them will not be a problem..

PM Sent..or will be..


PS....oh by the way...on the "customers" page...you will notice that some of the "entries" are yellow...those are the slims...the white ones are classics. I'm sure your smart enough to go directly to the folder they are located in rather than clicking each persons name.

Also I have a friends "sykowizard" who also has a customers page up there and he stores his in a different directory.

Your more than welcome to both sets of them.

Lately I have been looking at the data in ID Storage keys 0x100 and 0x101. I stumbled upon something that looks like a marker in the data.

In key 0x100 bytes 0x38 through 0x3F always seems to contain the value 0x00 0x00 0x00 0x01 0x00 0x05 0x00 0x03 (0000000100050003). The same value seems to be repeated at 0xF0 through 0xF7 and at 0x1A8 through 0x1AF.

The eight bytes that follow this value also seems to be same, but varies throughout different dumps of these keys.
It seems that ID Storage key 0x100 is split up in four sections. On page 1 it is described that ID Storage key 0x100 has the following functions:

* 0x100 - DNAS, VSH & Internet browser region, ad-hoc region (if missing, official updaters cannot run - error CTA80000025)

It could that each section has it own function as described above. I do not know if the whole key needs to be intact when used or that it uses only parts for various functions within the firmware. I am going to try to delete data within that key to see if something stops working.

It could show us which section in that key 0x100 has which function. maybe something like:

0x000 - 0x037 = DNAS
0x048 - 0x0EF = VSH
0x100 - 0x1A7 = Internet Browser Region
0x1B8 - 0x1FF = Ad-Hoc Region

Lately I have been looking at the data in ID Storage keys 0x100 and 0x101. I stumbled upon something that looks like a marker in the data.

In key 0x100 bytes 0x38 through 0x3F always seems to contain the value 0x00 0x00 0x00 0x01 0x00 0x05 0x00 0x03 (0000000100050003). The same value seems to be repeated at 0xF0 through 0xF7 and at 0x1A8 through 0x1AF.

The eight bytes that follow this value also seems to be same, but varies throughout different dumps of these keys.
It seems that ID Storage key 0x100 is split up in four sections. On page 1 it is described that ID Storage key 0x100 has the following functions:

* 0x100 - DNAS, VSH & Internet browser region, ad-hoc region (if missing, official updaters cannot run - error CTA80000025)

It could that each section has it own function as described above. I do not know if the whole key needs to be intact when used or that it uses only parts for various functions within the firmware. I am going to try to delete data within that key to see if something stops working.

It could show us which section in that key 0x100 has which function. maybe something like:

0x000 - 0x037 = DNAS
0x048 - 0x0EF = VSH
0x100 - 0x1A7 = Internet Browser Region
0x1B8 - 0x1FF = Ad-Hoc Region

The key is signed, if you edit it it will apear as corrupted data when checked by the kernel (through kirk)

Lately I have been looking at the data in ID Storage keys 0x100 and 0x101. I stumbled upon something that looks like a marker in the data.

In key 0x100 bytes 0x38 through 0x3F always seems to contain the value 0x00 0x00 0x00 0x01 0x00 0x05 0x00 0x03 (0000000100050003). The same value seems to be repeated at 0xF0 through 0xF7 and at 0x1A8 through 0x1AF.

The eight bytes that follow this value also seems to be same, but varies throughout different dumps of these keys.
It seems that ID Storage key 0x100 is split up in four sections. On page 1 it is described that ID Storage key 0x100 has the following functions:

* 0x100 - DNAS, VSH & Internet browser region, ad-hoc region (if missing, official updaters cannot run - error CTA80000025)

It could that each section has it own function as described above. I do not know if the whole key needs to be intact when used or that it uses only parts for various functions within the firmware. I am going to try to delete data within that key to see if something stops working.

It could show us which section in that key 0x100 has which function. maybe something like:

0x000 - 0x037 = DNAS
0x048 - 0x0EF = VSH
0x100 - 0x1A7 = Internet Browser Region
0x1B8 - 0x1FF = Ad-Hoc Region

This has always been known, the info on the first page is just a very brief summary of things (most of the info on there is from me). Keys 0x100/0x101 (and beginning of 0x102) together form 6 seperate independant sections. A section starts with the 00000001 bytes and is 0xB8 in length each (except for the last section which doesnt start with those bytes). These sections are signed/encrypted and can each be verified/decrypted with KIRK cmd 0x12, editing any part even a single byte of a section will then fail the KIRK cmd 0x12 verification.

All 6 are unique identifiers which can verify & authenticate the psp (for things like DNAS etc). There is one more 0xB8-Byte section at the end of key 0x101 and continues onto key 0x102 which doesnt start with the 00000001 string (last 0x30 Bytes of key 0x101 and the first 0x88 Bytes of key 0x102 together). This last section is what's called the 'Open PSID' and can be used to authenticate adhoc communications (the data after that in key 0x102 is the start of the umd keys).

IIRC the first section is what's called the 'PS Code', some sort of region verification. Dont remember what the other sections were.

In short, it's all signed so you cant edit anything and since that particular KIRK cmd just does the verification/decryption internally without passing back any data, we have no idea what the decrypted data looks like.

Oke, thanks for the information MathieulH and SilverSpring.

just wanted to say keep up the good work to the geniuses dedicated to getting all this to work! corrupted most of my flash an couldnt do anything but homebrew until i magically found my nand-dump on my computer!:eek: keep up the good work guys

...editing any part even a single byte of a section will then fail the KIRK cmd 0x12 verification.

Not entirely true.

Being myself, I randomely changed a few (threeish) bytes to nothing in particular in key 0x100, and all functions attributed to that key still worked.

Perhaps something just went wrong in saving my muntified key, however. :)

...editing any part even a single byte of a section will then fail the KIRK cmd 0x12 verification.

Not entirely true.

Being myself, I randomely changed a few (threeish) bytes to nothing in particular in key 0x100, and all functions attributed to that key still worked.

Perhaps something just went wrong in saving my muntified key, however. :)

No it is true, I wrote "...editing any part even a single byte of a section will then fail the KIRK cmd 0x12 verification". So any of these sections verified using KIRK cmd 0x12 will fail if any byte of that section is modified. However, not all sections are actually checked in the firmware (ie. not all are KIRK-verified). The first section is (the PS code - region verification), so try changing any of the bytes in that first section (offset 0x38-0xEF of key 0x100).

...editing any part even a single byte of a section will then fail the KIRK cmd 0x12 verification.

Not entirely true.

Being myself, I randomely changed a few (threeish) bytes to nothing in particular in key 0x100, and all functions attributed to that key still worked.

Perhaps something just went wrong in saving my muntified key, however. :)

No it is true, I wrote "...editing any part even a single byte of a section will then fail the KIRK cmd 0x12 verification". So any of these sections verified using KIRK cmd 0x12 will fail if any byte of that section is modified. However, not all sections are actually checked in the firmware (ie. not all are KIRK-verified). The first section is (the PS code - region verification), so try changing any of the bytes in that first section (offset 0x38-0xEF of key 0x100).

I was just speaking from my small experience, that explains it.

If I remember correctly (need to check) only two sections are actually checked in the firmware, the first section and the last section:

- PS Code: 0xB8 Bytes at offset 0x38-0xEF of Key 0x100.
- Open PSID: 0xB8 Bytes at offset 0x1D0-0x1FF of Key 0x101 and continued on to offset 0x00-0x87 of Key 0x102.

So if any part of those two sections are modified, then their corresponding functionality in the firmware will be broken. Editing other sections shouldnt cause any loss of functionality of the psp since they are not actually checked in the firmware (but will fail if you try to verify it with KIRK cmd 0x12).

SilverSpring,

If I am reading your explanation right, then in theory the ID Storage key 0x100 could be partially repaired to allow Ad Hoc. But the key will then still fail the KIRK cmd 0x12 for other functions, namely PS Code and Open PSID.

Correct?

SilverSpring,

If I am reading your explanation right, then in theory the ID Storage key 0x100 could be partially repaired to allow Ad Hoc. But the key will then still fail the KIRK cmd 0x12 for other functions, namely PS Code and Open PSID.

Correct?

Still a hell of a job, but as I see it, theoretically correct. At least, as long as Sony doesn't decide to do a full Kirk check on the keys :D

SilverSpring,

If I am reading your explanation right, then in theory the ID Storage key 0x100 could be partially repaired to allow Ad Hoc. But the key will then still fail the KIRK cmd 0x12 for other functions, namely PS Code and Open PSID.

Correct?

I don't quite understand, what do you mean by partially repair? If your key 0x100 is gone and you don't have a backup (and your key 0x120 is gone too) there is no way to repair.

I should be more clear, all the functions listed associated with key 0x100/0x101, dnas, adhoc, region, etc. uses PSCode/OpenPSID. So if these are broken, then your adhoc, dnas, etc. will be broken because they rely on PSCode/OpenPSID to do the verification & authentication of the psp. Key 0x100/0x101 are like signature keys, it has nothing to do with adhoc per se, adhoc communications uses these keys to do the authentication and thats why adhoc breaks if you lose these keys (same goes for all other psp functionality that need to do authentication too).

Other sections in key 0x100/0x101 are not used at all in the firmware (but possibly in future updates), so doesnt matter at the moment if they are broken. But if PSCode/OpenPSID are broken then everything that uses that will also be broken.

I don't quite understand, what do you mean by partially repair? If your key 0x100 is gone and you don't have a backup (and your key 0x120 is gone too) there is no way to repair.

I should be more clear, all the functions listed associated with key 0x100/0x101, dnas, adhoc, region, etc. uses PSCode/OpenPSID. So if these are broken, then your adhoc, dnas, etc. will be broken because they rely on PSCode/OpenPSID to do the verification & authentication of the psp. Key 0x100/0x101 are like signature keys, it has nothing to do with adhoc per se, adhoc communications uses these keys to do the authentication and thats why adhoc breaks if you lose these keys (same goes for all other psp functionality that need to do authentication too).

Other sections in key 0x100/0x101 are not used at all in the firmware (but possibly in future updates), so doesnt matter at the moment if they are broken. But if PSCode/OpenPSID are broken then everything that uses that will also be broken.

I meant with partially repair, to restore a segment in the ID Storage key 0x100. I already thought that ID Storage key 0x100 was being used in Ad Hoc communications, but I did not know that the PSCode/OpenSID was needed too.

So I am back at square one with thinking about this issue.

You cannot partially restore a key, the whole key is signed.

Mathieulh,

I understood that from what SilverSpring wrote. Btw, it is hard catching up with a few information available. I am guessing that the things I was thinking of already passed most devs minds. So now I have to try to think out side the box.

Here is a quick test that will verify each of those 6 sections in key 0x100-0x102 (using KIRK cmd 0x12):

http://silverspring.lan.st/certcheck.rar

It's a 3.xx app (src included), should work on all psps (tested on 3.52 fat and 3.90 slim).

If you modify any part of those keys, you'll see the app fail the check for that section. But you can modify any section apart from section0 & section5 (pscode & openPSID) and all features of the psp will still work fine, even though the app will fail the verify. Modify section0 (pscode) and you'll get region errors, modify section5 (openPSID) and you'll get adhoc/dnas errors.

Here are the offsets of each section in the idstorage key:

section0: 0xB8 Bytes from offset 0x038 of key 0x100 (this is the pscode)
section1: 0xB8 Bytes from offset 0x0F0 of key 0x100
section2: 0xB8 Bytes from offset 0x1A8 of key 0x100 (continues onto key 0x101)
section3: 0xB8 Bytes from offset 0x060 of key 0x101
section4: 0xB8 Bytes from offset 0x118 of key 0x101
section5: 0xB8 Bytes from offset 0x1D0 of key 0x101 (continues onto key 0x102) (this is the openPSID)

Only section 0 & 5 are used in the fw so that's why modifying any other section doesnt affect the psp's functionality.

Little is known about the format of these 0xB8 Byte sections and how they are generated, though it's constantly being researched. It doesnt seem to be one single stream of data but composed of seperate parts.

Nice app SilverSpring. As expected, my fat with broken 0x100 fails section0, 1 and 2 as these are the ones contained in 0x100 :)

I wonder why though, my section5 is fine, yet adhoc doesn't work?

I counted four sections in ID Storage key 0x100, so what does section 0x000 - 0x037?

/offtopic
I guess page 1 must updated if the ID Storage keys 0x100, 0x101 and 0x102 flow over into each other. Maybe the information about the sections from Silverspring can be added?

Well, 100 and 101 could be called one complete stream of 5 sections, and 102-106 could be called another. SilverSpring, how is the UMD decryption data split up? Is it similar to 100/101?

jas0nuk,

With key 0x101 I see 6 sections. Four sections in key 0x0100, two sections in key 0x101. The first section starts at 0x0000 and ends at 0x0037. Is that important data or something else?

Nice app SilverSpring. As expected, my fat with broken 0x100 fails section0, 1 and 2 as these are the ones contained in 0x100 :)

I wonder why though, my section5 is fine, yet adhoc doesn't work?

Hm really? I guess adhoc needs both pscode AND openPSID to work then. Btw, what does your key 0x100 look like now? Is it just empty? And what happened to your key 0x120, you broke that one too O.o ???? If it's still intact you can just replace your 0x100 with your 0x120.

Well, 100 and 101 could be called one complete stream of 5 sections, and 102-106 could be called another. SilverSpring, how is the UMD decryption data split up? Is it similar to 100/101?

Well, a stream of 6 sections (section 0-5) and it includes part of 0x102 as well (upto offset 0x88). Offset 0x88+ of 0x102 is the start of the umd data. The umd data is split up into 16-Byte "keys", so as you can see there are lots of them. The first part is like an index (the lots of 0's part), each entry is 8-Bytes and they map onto a 16-Byte "key" following the index upto the beginning of 0x106.

I counted four sections in ID Storage key 0x100, so what does section 0x000 - 0x037?



With key 0x101 I see 6 sections. Four sections in key 0x0100, two sections in key 0x101. The first section starts at 0x0000 and ends at 0x0037. Is that important data or something else?

I listed the offsets of each section above, these "certs" are 0xB8-Bytes in length, so there are 3 in 0x100 (the 3rd one is cutoff, it continues on in 0x101), and there are 3 in 0x101 (again the 3rd one is cutoff and continues on in 0x102). The first 0x38-Bytes in 0x100 isnt a cert, seems to be some kind of sig header maybe. It's not too important (for the sake of the psp's functionality that is). You can modify this part and it wont affect anything.

The 0xB8-Byte cert's seem formatted into something like this:

0x00: int (same for all sections for each psp)
0x04: int (same for all sections for each psp)
0x08: int (same for all sections for each psp)
0x0C: int (same for all sections for each psp)
0x10: buf[0x28] possibly siggen output?
0x38: buf[0x28] possibly siggen output?
0x60: buf[0x28] possibly siggen output? (constant, same in ALL psps)
0x88: buf[0x20] some type of sig?
0xA8: buf[0x10] some type of hash?

The only difference is the last cert (section5 - the openPSID) where the first 4 ints are instead just a 16-Byte id (rather than the 0's you see), which is the actual openPSID. Printing your openPSID, it should match the first 16-Bytes of section5. However the whole 0xB8-Bytes of that section is used to verify that the 16-Byte psid is actually valid.

Ah yeah 0-5 is 6 xD Just my dumbness.

And about my 0x100 and 0x120: when harleyg was trying to find out how to change the region, he came to the conclusion that it will only "change" if both keys are edited, if only one is edited, he said it read the region from 0x120. I'm not sure how he came to that conclusion, because looking at the code which scechkreg uses, it only reads 0x120 if 0x100 does not exist or fails to read.
Anyway, his tool therefore replaced both my 0x100 and 0x120 with the ones from his PSP, which obviously doesn't work. And I stupidly had no backup since he insisted it would work xD Anyway it's all in the past and I don't exactly miss using adhoc, but it's an interesting thing to look into. So yeah, I have no chance of restoring it from a backup or anything like that.

TA-088 key dump analysed, no changes to the non-unique keys except for 0x7 and 0x8.
Changed the descriptions to make them clearer (Slim v1/v2 instead of TA-085/088)

hi everyone. Sorry for posting here, i know is a forum for devs but im having a weird problem with a psp slim. The only firmware i can use is 3.71. Every time i update to a higher firmware it bricks. Even with pandora, the only firmware i can get working is 3.71 M33. I upgrade it to 3.80 (brick), 390 (brick), 4.01 (brick). While on 4.01 M33 i manage to toggle flash 0 and i notice all files were corrupt but i dont understand why only this happens after upgrading from 3.71 to any other firmware. I then flash anothers psp slim nand dump (of course after backing up my id storage keys and nanddump), but no luck still a brick. Can anyone give me feedback toward this issue. once again sorry for posting here.

That isn't really on topic, but anyway, it sounds like a hardware problem that only manifests itself on 3.80+ (unlikely but possible) - to see if the RAM is ok, check the last post in this topic: http://forums.maxconsole.net/showthread.php?t=117116

Firmwares after 3.71 went nuts if flash2/3 (4 possibly on slim, as well, but I've never seen it happen) weren't formatted to the correct version/cypher - it basically corrupts memory (resulting in a crash/black screen) somehow when it tries to load the lflash/lfat drivers and one of the partitions doesn't match the version. If the mem test works out with a bunch of OKs (and I'm not entirely sure it will test slim extended memory, but I think it won't), then try using nandTool and/or flash23 format to repartition and format the partitions to the firmware you want to install (basically means making sure the right _updater prx's are in place.)

This could easily happen if you are using a badly made des.cem stick with mismatched prxs or a corrupted partition record (tool to check that from pandora here (http://nds.cmamod.com/2008/06/22/lflash-check/)) - if the partition records are corrupted when it goes to format a partition it doesn't fail with an error sometimes (from pandora at any rate), it just acts like it worked.

Good luck, at any rate (and here's hoping you aren't caleebra with the failing DRAM.)

@jas0nuk
"Looks like your PSP is broken, you can sell some parts like jas0nuk told you before.
Good luck!"
(that's the last post)
lol xD

That wasn't the last post when I posted the reply xD

Here is the post I was referring to: http://forums.maxconsole.net/showpost.php?p=980672&postcount=11

But as cory1492 has given an alternative explanation, maybe the RAM test isn't needed.

oh ok lol
10 chars min

Today I bought a slim. It is (I believe) a TA-88 - the one that can have cfw applied but cannot create a pandora battery.

Edit: PSPident 0.3 states it is a TA-088 - it came with 3.90 ofw.

A couple of months ago there was interest in obtaining a virgin (pre 1st boot) nand dump.

I recall that it was concluded that nothing happened to the keys pre/post 1st boot - but in any case I did take a pre 1st boot nand dump.

If there is still any interest/value in taking a look at this, let me know and I will forward it on.

hi all.

I must be one of the lucky ones cos i believe i just fixed my slim to 100% working again. with no backup of my keys after bricking my slim when first learning about CFW.


now, this thread hasn't been used for a while, so maybe a cure has already been found. forgive me for waking the dead. :-)


Luck my wife and i have identical PSP-2002PB 's.

i flashed her nand onto my psp. got it running again with the usual probs. wifi, umd, SCE updater. (before learning that was a very bad thing to do)

using keycleaner and IDSM, i got wifi back

I've had the CTA80000025 error for a while

but with her nand, IDSM, keycleaner, DC8 and most importantly your posts, it's now fully fuctional. adhoc, UMD, wifi, SCE updater all work.

have i stumbled onto a cure using ur tools, or did you guys plan it that way.....

You are behind the times...

Despertar Cementario includes in the last 2 or 3 versions an idstore rebuilding function which gets correct keys for most of the per-psp crypted keys, probably since shortly after this thread was last used.

actually the idsregeneration code is in there since DCv7 and err... yeah it is there on purpose :p It has the ability to restore every keys but the magicgate ones, it is also the result of over 2 years of intense research so indeed it was purposefully added :)

I have a PSP Fat TA-79 V2, the psp was bricked for two months and today i accidentally flash a full (Including IDStorage keys) *.bin file of the TA-81 motherboard all games and functions are working but the only problem is that the game sharing would not work. I have already used the MAC Address Fixer and Key cleaner and they all said that it was fixed but the game sharing does not work.

Congratulations? :confused:

Thanks :confused: but with the Adhoc or Gamesharing feature does not work, but i can still browse the internet if i use the Wifi feature. Is there a possible way to fix this? As i have not have any backup copies of the original ID Storage of the psp. ***** I think i posted on the wrong thread ******

Despertar Cementario 8 (DC8) can regen idstore, not sure if it will fix adhoc stuff though.

Despertar Cementario 8 (DC8) can regen idstore, not sure if it will fix adhoc stuff though.

STUB_START "idsRegeneration",0x40090000,0x00130005
STUB_FUNC 0xBDE13E76,idsRegenerationSetup
STUB_FUNC 0xFEE3C55B,idsRegenerationGetIndex
STUB_FUNC 0x0B33639A,idsRegenerationGetHwConfigKeys
STUB_FUNC 0xFEA979A6,idsRegenerationGetMGKeys
STUB_FUNC 0xEE1AD992,idsRegenerationGetFactoryBadBlocksKey
STUB_FUNC 0x87A30D3A,idsRegenerationGetSerialKey
STUB_FUNC 0xE37CC2E6,idsRegenerationGetWlanKey
STUB_FUNC 0xC44FE956,idsRegenerationGetAudioVolumeSetupKey
STUB_FUNC 0xBC42FEED,idsRegenerationGetUsbKeys
STUB_FUNC 0x3F014928,idsRegenerationGetUnkKey140
STUB_FUNC 0x8F7EE9C0,idsRegenerationGetMGKey40
STUB_FUNC 0xB9156F27,idsRegenerationGetUnkKeys3X
STUB_FUNC 0xB417BCF0,idsRegenerationGetParentalLockKey
STUB_FUNC 0xFA2368E8,idsRegenerationGenerateFactoryFirmwareK ey
STUB_FUNC 0x0EF8731D,idsRegenerationGetLCDKey
STUB_FUNC 0x4E95D36F,idsRegenerationGenerateCallibrationKey
STUB_FUNC 0xD7603D82,idsRegenerationGetUnkKeys5253
STUB_FUNC 0x6015A7CD,idsRegenerationGetDefaultXMBColorKey
STUB_FUNC 0xB79A6C46,idsRegenerationCreateCertificatesAndUMD Keys
STUB_END

Just WLAN... I always thought the only thing that could not be done with DC7/8 was regeneration of the MagicGate keys, however idsRegenerationGetMGKeys seems to suggest otherwise...

Well, then I'd suggest when browsing internet check with the AP for the PSP's actual mac address and make sure it is the same one xmb reports to you in system settings. Provided you actually have regenerated your idstore with DC8 instead of just relying on "what seems to be working" from the misflash.

Just WLAN... I always thought the only thing that could not be done with DC7/8 was regeneration of the MagicGate keys, however idsRegenerationGetMGKeys seems to suggest otherwise...

You can get the Magic Gate keys, but correctly signing them is a different story.

I knew someone would ask this sooner or later. I just thought it would be some place else.

Just WLAN... I always thought the only thing that could not be done with DC7/8 was regeneration of the MagicGate keys, however idsRegenerationGetMGKeys seems to suggest otherwise...

You can get the Magic Gate keys, but correctly signing them is a different story.

I knew someone would ask this sooner or later. I just thought it would be some place else.

I see... are the MagicGate keys the only ones which are signed?

lol, where did you think it'd be asked?

<Off topic>Recently I've heard much about PSARDumper and decryption keys, mostly in topics entitled with "5.55 Firmware oh noes!" Mathieulh has commented on this:

Update the custom firmware's kernel to 5.55 or decrypt the games EBOOT.BIN (after getting the new keys)

Great, but is there any documentation anywhere as to how these keys are obtained? I'd like to mess around with it.</Off topic>

Just WLAN... I always thought the only thing that could not be done with DC7/8 was regeneration of the MagicGate keys, however idsRegenerationGetMGKeys seems to suggest otherwise...

You can get the Magic Gate keys, but correctly signing them is a different story.

I knew someone would ask this sooner or later. I just thought it would be some place else.

I see... are the MagicGate keys the only ones which are signed?

lol, where did you think it'd be asked?

<Off topic>Recently I've heard much about PSARDumper and decryption keys, mostly in topics entitled with "5.55 Firmware oh noes!" Mathieulh has commented on this:

Update the custom firmware's kernel to 5.55 or decrypt the games EBOOT.BIN (after getting the new keys)

Great, but is there any documentation anywhere as to how these keys are obtained? I'd like to mess around with it.</Off topic>


Those keys are obviously obtained through the reverse of various kernel components (if it is game keys you are looking for, you might want to take a closer look at mesg_leg.prx (at least if things haven't changed too much since last time I looked into it ))

I am unaware of any kind of specific documentation to help you through the process. Also I do hope that you have a legit excuse for getting those keys as we are (at lan.st at least) against piracy and the 5.55 firmware on its own does not bring anything new next to the 5.50 (which already exists as a custom firmware)

Of course not being able to play new games on custom firmwares greatly handicap people that actually purchased those but they are a minority next to people who only want new games support for piracy (sad but true :/ )

Anyway if you are skilled enough to extract the new keys and use them, I believe you should be smart enough to decide whatever should be done of this work (providing it is yours).

Those keys are obviously obtained through the reverse of various kernel components (if it is game keys you are looking for, you might want to take a closer look at mesg_leg.prx (at least if things haven't changed too much since last time I looked into it ))

I am unaware of any kind of specific documentation to help you through the process. Also I do hope that you have a legit excuse for getting those keys as we are (at lan.st at least) against piracy and the 5.55 firmware on its own does not bring anything new next to the 5.50 (which already exists as a custom firmware)

Of course not being able to play new games on custom firmwares greatly handicap people that actually purchased those but they are a minority next to people who only want new games support for piracy (sad but true :/ )

Anyway if you are skilled enough to extract the new keys and use them, I believe you should be smart enough to decide whatever should be done of this work (providing it is yours).

Mathieulh, the reason i ask is not for piracy, merely because i have seen (as you have, Ref: your post on MaxConsole (http://forums.maxconsole.net/showthread.php?p=1168373#post1168373) (Side note: do you know how many people idolise you there?!)) many threads on 5.55 (As is the scene, moaning, ridicule etc...), i simply wondered what the inner workings of it where, how the decryption happens, what cipher is used, how/why it is scrambled, how the keys are obtained etc, clearly i am not at the skill level required (I have read the 5.50 PSARDumper source, and can see the existing keys for various firmware versions, and descrambling techniques, but nothing on actually obtaining the keys). I asked purely out of curiosity, rather than the need to play games that require 5.55, currently that issue doesn't effect me.

Those keys are obviously obtained through the reverse of various kernel components (if it is game keys you are looking for, you might want to take a closer look at mesg_leg.prx (at least if things haven't changed too much since last time I looked into it ))

I am unaware of any kind of specific documentation to help you through the process. Also I do hope that you have a legit excuse for getting those keys as we are (at lan.st at least) against piracy and the 5.55 firmware on its own does not bring anything new next to the 5.50 (which already exists as a custom firmware)

Of course not being able to play new games on custom firmwares greatly handicap people that actually purchased those but they are a minority next to people who only want new games support for piracy (sad but true :/ )

Anyway if you are skilled enough to extract the new keys and use them, I believe you should be smart enough to decide whatever should be done of this work (providing it is yours).

Mathieulh, the reason i ask is not for piracy, merely because i have seen (as you have, Ref: your post on MaxConsole (http://forums.maxconsole.net/showthread.php?p=1168373#post1168373) (Side note: do you know how many people idolise you there?!)) many threads on 5.55 (As is the scene, moaning, ridicule etc...), i simply wondered what the inner workings of it where, how the decryption happens, what cipher is used, how/why it is scrambled, how the keys are obtained etc, clearly i am not at the skill level required (I have read the 5.50 PSARDumper source, and can see the existing keys for various firmware versions, and descrambling techniques, but nothing on actually obtaining the keys). I asked purely out of curiosity, rather than the need to play games that require 5.55, currently that issue doesn't effect me.

Well most of the keys are obtained from the IPL itself, they are located inside main.bin and used to bootstrap the kernel modules. You can decrypt the IPL directly using the forged IPL block and the pre-ipl code (this has to be done at IPL time)